Regional Webcasting - Confusing

My recent experience with the webcasting portal for a Regional event was very confusing and problematic.

I've spoken with the GSC about some of my issues (even a higher tier) but I feel letting others know about these issues will help them through confusion in case modifications to the portal don't come.

Here's a little background. My stake is hosting a 10-stake devotional hosted by an Apostle and I am responsible for the success of the broadcast to 9 locations in different stakes. Since this was my first time with an event this large, I found getting things set up was complicated and confusing. There is a lot of information you will need for scheduling and completing the event. When we had our first test broadcast, it failed miserably. Some of the reasons and confusing issues are listed below. Hopefully this information will help you have better success than I.

Setting up receiving locations for other stakes is a little complicated. You will need to know the following from each stake.

• Unit Number ID and Stake Name (to see and assign receiving locations of a different stake)
• The address of the receiving building or name listed for the location (to select the receiving location)
• The lds.org username for the assistant (to add to your profile for the new assistant assignments and to gain access)
• Assistant's contact information

When adding receiving locations, you may discover buildings which are shared by multiple stakes. What gets confusing is when an assistant logs into the Portal and scrolls down for his building and selects the building's name which looks familiar to him, but that location was reserved for a different stake. The actual stake the location was intended for cannot connect and view the URL because the link is in use by the first assistant. Another issue we had was when a receiving location had been disconnected, and attempts to reconnect through the Portal fail. The URL reports the location is in use, and you can not connect. The Global Service Center's solution to this situation is to use the Event Code for the webcast. We found a solution by creating hyperlinks and saving them on the desktop, bookmarks or in emails. We found we could successfully reconnect and even bypass the portal. I just prepare an email to all the assistant with hyperlinks pointing them to the proper link for their building: Lastly, when monitoring the health of the receiving locations, you may find it difficult to know who to contact regarding a problem. You will not know who the assistant is or stake receiving because the only reference you will have available is the name of the building. Hopefully the Portal will be modified in the future to show the assistant's information next to the location name.

Very good information.

Its hard to configure a system for something that it wasn't truly designed for.

Your other options is to use PVC and have everyone join your room. Just a suggestion.

Terry

A word on the disconnecting of the receive sites and using the Event Code.
When a receive site disconnects it takes the browser 30 seconds up to around a minute for the session to disconnect, thus letting the portal know the link is free. While the session is still connected, the portal will not let anyone use the link. This is so as to not bungle up the stats of the receive site. If the portal were to allow multiple uses of the link then the stats would become confused and very messy making it impossible to know what is going on.

When using the Event Code, it breaks the receive site into parts. So there is not a continuous report. This can make it a challenge to track down which Other site is the receive site, so thus discouraged. Basically use at your own risk.

rannthal wrote:Its hard to configure a system for something that it wasn't truly designed for.

I wonder if our region is using the old system. We have regional training broadcasts every few months. I get a URL by text or email the day of the broadcast, hit it with my Firefox browser, and we are off and running. The originating stakes (it varies) have never asked for our unit number or anything of the sort (although it is readily available to them).

rannthal wrote:When a receive site disconnects it takes the browser 30 seconds up to around a minute for the session to disconnect, thus letting the portal know the link is free. While the session is still connected, the portal will not let anyone use the link. This is so as to not bungle up the stats of the receive site. If the portal were to allow multiple uses of the link then the stats would become confused and very messy making it impossible to know what is going on.

When using the Event Code, it breaks the receive site into parts. So there is not a continuous report. This can make it a challenge to track down which Other site is the receive site, so thus discouraged. Basically use at your own risk.

While I understand the technical reasons for that, please realize that if the event is interrupted, no one is going to sit on their thumbs for 30/60 seconds waiting for things to time out. Nor is the above answer likely to satisfy anyone at the receiving site (or the stake presidency). They're going to want re-connection ASAP by any means necessary.

That's the technology we work with. It is what it is.
So you can pick your poison. Either losing stats or waiting.

Mind you this only happens when the player truly loses connection. The silverlight player will try to reconnect without any outside influence and nothing is lost. We are working on having the new player do the same thing.
It is only when the browser is refreshed or if the page that the new player is on is gone away from that this happens.

rannthal wrote:That's the technology we work with. It is what it is.
So you can pick your poison. Either losing stats or waiting.

I doubt if anyone is terribly interested in the stats. At best it's a means to an end.

It's just another reason why local units may end up using an unofficial method, even if they have to bypass the firewall to do it.

Stats are there for a reason. It is for the STS to monitor there sites and head off any problems that may occur. It is also for the support and engineers to have and analyze after the event when things to go wrong to correct them.

Let me give you an example that has occurred many times in the past. With the old system and event occurs, but and at the receiving site the something happened and the comm box stopped. Why did it stop? Is it the Internet? Is is the laptop? Is it just isolated to the receive site or are more receive sites having the same issue? Is the broadcast site having problems? Is the encoding site trying to encode higher that what it has bandwidth for?
Now with all those questions, try calling the GSC and explaining what happened on the fly so they can help YOU fix the issue. Do you have all that information to the questions that I asked above? Where is the proof that something is happening? How do you correct something that you do not know what the issue was in the first place?

The stats provide all the answers to the questions above.

russellhltn wrote: I doubt if anyone is terribly interested in the stats. At best it's a means to an end.

Try telling that to someone that has had problems and it trying to figure out what went wrong and why. They are glad they have them.
I am sure glad the stats are there because when I've had problems at my stake conference when the Internet dropped 4 times, I was glad that I could see what happened to the conference as a whole. Using those stats I was able to recreate the problem and we are correcting the issue at our stake center. Without the stats all it would be is a bunch of guess work.

Let me remind you that no one is twisting your arm to use the system. Your stake is not charged to use it. It is a service that is provided to members of the church to use. If you want to use a different system that works better for you to allow the members of your stake to hear the word, please do so.

I'm just going back to this:

So you can pick your poison. Either losing stats or waiting.

I'm sure the stats are valuable - postmortem. In the heat of the moment, not so much. That's going to weigh heavily in the decision.

And this is where the STS is going to have to make a decision wait 30 seconds and reconnect, or grab the event code, go to the Home page, put the Event code in, click the button and bring up the player.....which would take at least 30 seconds anyway, and then try to piece together the stats and the logs to figure out what went wrong.

The system is just a tool provided to the stakes to use to allow its members to hear the word. How the system is used is up to the STS. They can use all the tools provided or hardly any at all, its entirely up to them. They need to figure what works for their stake for present and future events.

I've been there when sites have went down and a decision must be made on what to do. Here is what I do:
1. Pending on the player used, wait to see if the player will reconnect on its own, I give it about 30 seconds.
2. If not, I refresh the browser.
3. If the player can not connect and times out, then I'll refresh it again.
4. If the player times out again, something went very wrong somewhere and would try the Event Code just to get the stream back up and running. If that works, great its up. If not....then something went very wrong.

As the STS you have been blessed and set apart to be able to fulfill your calling and make good judgements. The Holy Ghost will help you know what to do. Listen to the Him. He will be there and help you if you seek Him out.

Yesterday was our normally scheduled stake conference. We did a test with the new webcasting system and it worked great. I have read this post and I agree with the receiving sites needed to be in there and it would be great to have the user who will be assistance at that building. However, I found out yesterday, at least the way that I set it up, that a member with a LDS.ORG account can use the meeting code and get into the meeting. So I don't think the assistant in each building would be necessary, but very helpful so that if anything goes wrong that they can get the site back up and running.

Thanks