Gremlins in the Meetinghouse Webcast software

Conversations around originating a webcast for conference, including cameras and mixers.
lionelwalters
Member
Posts: 102
Joined: Wed Mar 12, 2008 6:38 pm
Location: Australia
Contact:

Gremlins in the Meetinghouse Webcast software

Postby lionelwalters » Sat Jul 24, 2010 2:43 pm

Hi there,

I'm hoping someone can assist or put me in the right direction for some help on this strange issue. We're a very small stake in numbers so along with serving in the stake presidency, I fill in as the stake technology specialist (for computer-related technologies). We're spread across a fairly wide geography so we've been exploring using webcast in a limited fashion to cut down on travel.

Just under a year ago, our stake experimented with using the Webcast software to broadcast a funeral. After a week of thorough testing, we saw some audio/video sync issues that ended up manifesting themselves in the broadcast on the day. The video was delayed by the expected minute or so, but the audio lagged behind that a further 2 or 3 minutes (so the first 2-3 minutes of the broadcast were silent). When I spoke to the folks at the GSD, they were at a loss to explain the issue so we had to just live with it this time.

A year and some sporadic testing later, we finally felt confident to try it again. We sought approval from a visiting Seventy to webcast a fireside he was to preside at. Again, I spent hours at the chapel testing and retesting to make sure everything worked. I was pleased to observe that the sync issues did not appear in any of the testing this time. I tested streaming from the host chapel, other chapels and from home; I tested receiving from the host chapel, other chapels and from home. Everything worked perfectly and consistently!

Then last night I got to the chapel two hours prior to the fireside to set things up. I was quickly satisfied that everything was looking great from the sending end, but then I set up a receiving terminal. Despite a week of consistently perfect results, the sync issues appeared just as they had a year ago. I tried stopping and restarting the stream, but this resulted in the receiving ends being unable to connect to the stream again after it had stopped (even up to 5 minutes later - the sending end appeared to be sending fine, but the receiving WMP could not find or connect to the stream)! I had to create a new event ID for it to even stream again, but still the sync issues persisted. I tried changing the upload speeds (our buildings have 20/1mbps connections, but because we never achieve these optimum speeds, all my testing had been using the 100kbps setting, which had yielded the perfect results I've mentioned; I increased it to the 200kbps setting this time), then tried using a different PC to initiate the stream. By this time I was running late for a meeting with the visiting authority, so despite my efforts to fix it at my end, I had no success and the result was a very embarassing and less than effective webcast experience.

I'd love to speak with someone who specifically supports the backend of this service, and perhaps run some tests with them. We want, of course, to use the Church's supported product, but something needs to be fixed if this is going to be the consistent outcome. Any thoughts or contacts would be appreciated.

Thanks in advance!

Lionel Walters

rmrichesjr
Community Moderators
Posts: 1038
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon

Postby rmrichesjr » Sat Jul 24, 2010 5:57 pm

Here are some ideas of things to test that might lead toward an explanation and maybe a solution:

What results do you get when you run a generic internet speed test at both the sending and receiving sites? If your ISP is limiting your bandwidth, that could account for some problems. Some months ago, my ISP _said_ they were increasing my home bandwidth from 5/2 to 10/2, and one of the several software download sites I frequently use did double in speed--but several other sites actually _decreased_ by about a factor of two.

What packet loss rates do you see when pinging sites that answer ping? (I have had good success testing packet loss by pinging yahoo.com, for one example.) To get meaningful results, you'll need a _real_ ping program that can send at least a few dozen packets, not just four. If you're losing more than 5-10% of ping packets, that could explain some problems.

If your successful testing efforts have been on weekdays but the problems occur on Sunday, make sure to test on Sunday. Your ISP might show different bandwidth and/or packet loss rates on the weekend vs. during the week.

If you can set up a machine capable of running Wireshark to monitor the packet stream during a webcast attempt, see if you are seeing anything odd. If you're losing a lot of packets while streaming (but not while pinging) that could be part of the problem.

Good luck.

techgy
Community Moderators
Posts: 3174
Joined: Sun Jan 13, 2008 6:48 pm
Location: California

Postby techgy » Sun Jul 25, 2010 9:17 am

A couple of years ago, prior to the software you're referring to, our stake participated in an evening with a general authority via a audio/video link with CHQ. The equipment to perform this somewhat magical feat was provided to us in advance and we set about becoming familiar with it.

About 3 days prior to the actual event a test was scheduled. We experience drop-outs and sync problems that were traced to the distance we were running from the chapel to the DSL modem. We had used a CAT 5 cable to run the approximately 105 feet from the chapel, down the hall to our family history room where the DSL modem was placed.

The solution was to move the modem into the chapel. We ran 105 ft of telephone cable from the chapel to the FH room where the DSL phone line was then ran a short length of cable from the modem in the chapel to the broadcast equipment.

This is just a thought since I'm not familiar with the new webcast software and haven't had a chance to use it.
Have you read the Code of Conduct?

russellhltn
Community Administrator
Posts: 20767
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

Postby russellhltn » Sun Jul 25, 2010 12:18 pm

Since the failures happen when members are present, you might want to take steps to make sure you have exclusive access to the network and make sure no one is running updates on the Ward /FHC computers or using the wireless.
Have you searched the Wiki?
Try using a Google search by adding "site:tech.lds.org/wiki" to the search criteria.

Aczlan
Member
Posts: 351
Joined: Sun Jun 06, 2010 4:29 pm
Location: Upstate, NY, USA

Postby Aczlan » Sun Jul 25, 2010 8:22 pm

rmrichesjr wrote:<snip>
What packet loss rates do you see when pinging sites that answer ping? (I have had good success testing packet loss by pinging yahoo.com, for one example.) To get meaningful results, you'll need a _real_ ping program that can send at least a few dozen packets, not just four. If you're losing more than 5-10% of ping packets, that could explain some problems.

If all you want to do is test ping times for a meaningful number of pings, run the following from a command line:

Code: Select all

ping -n 50 lds.org

That will sent 50 "ping" requests to lds.org and give you the statistics for them. Will work on Windows 2000 or later, may work on earlier versions of Windows.

If you can set up a machine capable of running Wireshark to monitor the packet stream during a webcast attempt, see if you are seeing anything odd. If you're losing a lot of packets while streaming (but not while pinging) that could be part of the problem.

For a simpler way, look at the "statistics" box that comes up on the webcast software, it comes up when you are streaming and will show you how much data has been encoded, sent and lost. You could also run the above ping command while broadcasting and see if there are any differences when things get bad.

For a long term (ie: to get the averages for a whole broadcast session) run:

Code: Select all

ping -t lds.org

Then hit Control + Break ("Pause") to get the current stats while still monitoring or Control + C to stop monitoring and get the final stats.
Running ping -t lds.org will ping lds.org until you tell it to stop (by closing the window, hitting control + C or shutting down the computer).

Aaron Z

lionelwalters
Member
Posts: 102
Joined: Wed Mar 12, 2008 6:38 pm
Location: Australia
Contact:

Postby lionelwalters » Sun Jul 25, 2010 9:36 pm

Thanks for the suggestions so far. I've tried the ping tests suggested and there were no drops in 50 requests. Bandwidth via SpeedTest.net averages at about 8mbps/.5mbps, so easily enough to support a 100kbps stream. Re. wireless, we have restricted access to leadership, none of which were using it at the time of the webcast. The single FHC and admin computers at the host building were off at the time of the webcast. Everything was the same as during my several tests the week before. It failed only on the evening on the webcast (a Saturday night). It's working again today...

So there were two issues that occurred on the night, but not before and not since:
- Audio and video out of sync by about 3 minutes. Video was at the expected rate but audio was delayed significantly.
- When I stopped the webcast and restarted using the same event ID, the receiving ends could not reconnect to the stream. The sending unit showed data going out with no packet loss. I had to change the event ID in order for receiving ends to be able to connect.

Appreciate your thoughts and input.

rmrichesjr
Community Moderators
Posts: 1038
Joined: Thu Jan 25, 2007 11:32 am
Location: Dundee, Oregon

Postby rmrichesjr » Mon Jul 26, 2010 8:32 pm

Sorry if you said so and I did not see it. Did you do any of your speed tests on a weekend? I would guess there would be more kiddies downloading music/video/etc. on the weekend, and your ISP's pipe to the outside world might have been overloaded. If you can afford the time, I'd suggest a few tests on consecutive weeks at the same time as the problematic broadcast.


Return to “Webcasting”

Who is online

Users browsing this forum: No registered users and 1 guest