What to use for Stake Conference Video Broadcast??

ksolsen · #11

stelring wrote:Yeah, that's what we did at the broadcast point and had it tied to ethernet only.

Also, we were monitoring the connection and it had no issues pushing the data, wasn't even near capacity.

So my guess is the church systems were slammed and couldn't hold connections.

@stelring: if you could provide the date and time when you experienced the connection errors, I can have our engineers look at the webcast server logs and see if there was something specific going on.

You should also know that we are just starting several projects to improve the reliability and availability of the webcast servers. There is one particular server load-balancing arrangement in place right now that has given us some occasional problems which we are replacing, which I'm confident will be a good improvement.

I agree with the other suggestions on this thread to also take a look at PVC. The infrastructure is on completely separate hardware; it also offers the advantage of being based on H.264 SVC (Scalable Video Coding), which is a technology that adapts very well to fluctuating Internet bandwidth. In a broadcast scenario, you'll want to simply mute the audio (or better yet, don't even worry about connecting up audio inputs) at the receiving locations, since PVC is set up as a 2-way communications product but you really only need 1-way in the stake conference broadcast scenario.

Sorry to hear of your problems. Trust me, it's painful for those of us here at Church HQ who manage these products to hear of issues that negatively affect the success of meetings. We are working hard to do all we can to provide reliable products. I appreciate the honest comments, and please know we are in the continuous improvement mode.

johnshaw · #12

Kurt,

I've found the greatest amount of negative feedback was from those unprepared for the event. We just did a successful broadcast for a 12-stake event, and reports came back that the broadcast was a 'mixed success' yet the majority of people had 100% success... some areas that failed to properly prepare were the ones that had bad experiences... my feedback is we could use a consistent message about 'how to prepare to receive a webcast' - an update to the wiki, similar to the one promised about using PVC...

sammythesm · #13

ksolsen wrote:Sorry to hear of your problems. Trust me, it's painful for those of us here at Church HQ who manage these products to hear of issues that negatively affect the success of meetings. We are working hard to do all we can to provide reliable products. I appreciate the honest comments, and please know we are in the continuous improvement mode.

Thanks for your participation in the forum, Kurt. It's great to be able to interact with people at CHQ who know the details behind the systems.

ksolsen · #14

sammythesm wrote:Thanks for your participation in the forum, Kurt. It's great to be able to interact with people at CHQ who know the details behind the systems.

Thank you. It's great having such an active user community, discussing issues like this and offering great suggestions and advice. There's not enough of us on the team at HQ to anticipate every situation or come up with every idea, so the community team effort is great.

ksolsen · #15

JohnShaw wrote:Kurt,

I've found the greatest amount of negative feedback was from those unprepared for the event. We just did a successful broadcast for a 12-stake event, and reports came back that the broadcast was a 'mixed success' yet the majority of people had 100% success... some areas that failed to properly prepare were the ones that had bad experiences... my feedback is we could use a consistent message about 'how to prepare to receive a webcast' - an update to the wiki, similar to the one promised about using PVC...

John - I agree. Proper preparation is the key. And I think generally people are willing to do the work to prepare, but need some guidance. I have it on my backlog (along with the guidance on setting up to use PVC in a large-hall scenario) to write a guide on webcast that provides important preparation steps and a troubleshooting guide. I will get to that as soon as I can!

johnshaw · #16

Web Broadcast - Hooking Audio to the Chapel.pdf: (713.73 KiB) Downloaded 913 times

Here is what we've prepared in the past... it's rudimentary, and the pictures could be improved, but I think pretty helpful. Maybe something with some video, etc...

johnshaw · #17

One additional point might be good as well. Frankly, if you don't use a wired connection to upload and download the broadcast, you are just begging for issues. In this 12-stake area, I referred to earlier, I'd guess that we only have about 10% of our chapels with wired connections to clerk/chapel - we might have wireless spread around, but our FM is not making this a priority. It seems that with PVC, and Webcast that this is a must. What I'd like to see is some muscle from the top... A letter that goes out to all Stake Presidents, Bishops, and FM saying in essence... in order to provide the greatest experience using technology, FM groups should work with local stake presidents to implement WIRED connections to ALL buildings in the church. It is implied in many places, but I can tell you that until this is sent out from the Presiding Bishop, our FM group will continue to say... well, that's not my understanding, or I don't have budget or whatever the flavor of the day is that really means, I'm busy, and have a bunch to do, that's just more work.

stelring · #18

Thanks for the input Kurt!

I believe it was the Sunday 18th of September 2011 between 9:30am and 12pm MDT where we had the problems.
Prior to that a few days before I had successfully streamed for about 5 hours, and another 4 hours to the other two buildings in the stake, with no problems.

We ran everything wired, not wireless and disabled access to the rest of the network.
We also monitored the network for faults during the broadcast and there was no interruption or slowdown of internet service.

I think it broke connection with the server over 20 times during the broadcast with different errors at times like, "port error" and "server error" or would just plain quit broadcasting after about 30 seconds.
The clients worked just fine as long as the server was connected and broadcasting, so we didn't have any problems there.

A lot of members in the two Ward buildings left because of the problems.

I guess I could use it again this Sunday, but is there anyone on hand this Sunday that I could stay in contact with in case I have problems?

How do I get this PVC stuff installed on my laptop and running, if you think that would be better?

Thanks!
Sterling

ksolsen · #19

Sterling - very sorry that your last experience went so poorly. It really sounds like you had the proper setup and did some good testing in advance. I don't think our log files will go back as far as September of last year.

I would suggest the following:
- Do some testing this week with Meetinghouse Webcast. Let me know how that goes. If you have problems, please note the date and time so we can investigate.
- Get yourself set up on PVC as a backup solution. Send me an email at kurt.olsen@ldschurch.org and I'll give you some additional info.

Thanks.

Kurt

sammythesm · #20

So... while we're on this thread about quality issues - my quality issues seem to always be on the receiving end. This last Sunday during our Stake Conference we had one building that was solid as a rock. The second building had to connect multiple times before the broadcast in order to receive audio, and then had a few audio drop outs during the broadcast. I also heard that the video turned green for a few seconds as well (though the audio continued).

Any suggestions on why this might be happening from an infrastructure perspective? Is is that the WMP stream is not adaptable and so is very brittle and sensitive to any fluctuation in bandwidth at the receiving end? Is a server issue where the feed has to connect multiple times before getting a "good" or "solid" feed? I'm confident we had good throughput in the building throughout the meeting, so I really don't suspect a local internet problem. I mean, sure, there may have been slight fluctuations in bandwidth, but we have 12mbps down at the building, so it still should have been plenty of BW even if it fluctuated a bit.