Webast receiving site loses connection with spinning circle

So we conducted a test yesterday in preparation for an upcoming stake conference webcast. During the session we had two receiving locations go into a disconnected state. The reported a spinning circle. The event main page still showed them connected, and if they closed a browser and tried to get back in they couldn't saying that the site was still connected. (two other sites had no issues the entire webcast.

The only thing I can think of in preparation for this event is to include the event code so they can immediately jump into another session without waiting for some kind of built-in time-out to recognize the connection is broken.

Does anyone know about this behavior and why it occurs? I'm afraid it's the Digis/Rise Wireless broadband, anyone out there using that technology experience similar results? CHQ, do you have reports of this on Digis/Rise.

Is there anything that can be done to quickly reset the connection? Should I create a secondary site for each location in preparation of an issue?

thanks!

What browser are they using at the receiving sites? in my test, it seemed like Chrome and Edge worked the best. Firefox had issues with the Silverlight pug in.

IE was being used by one and Chrome by the other. In the other site receiving station, we had a MAC using firefox and a PC using firefox, and chrome.

Are you saying that Chrome and Edge work best when this sudden disconnect happens? All sessions were flawless, it was just that both of these sites, in some way, lost connection, once reconnected it worked perfectly to the end.

Does anyone know about this behavior and why it occurs? I'm afraid it's the Digis/Rise Wireless broadband, anyone out there using that technology experience similar results? CHQ, do you have reports of this on Digis/Rise.

From what I have heard, sometimes wireless systems will drop for a quick second, which for streaming can cause problems. When this happens with the Primary player, it causes a disconnect. In order reconnect, the page needs to be refreshed and its possible to get blocked because the system still thinks the browser is connected. The player then has to wait for its timeout to expire in order for it to reconnect. (Its a pain. I know, but there is some relief coming.)

To solve this, the best way is to do what you described in having the event code and then jump to the Home page and enter it there. Other then that its waiting for the timeout to expire, which usually is somewhere between 30 seconds to a minute.

However, with our next update, the player will have some updates where it will refresh automatically if it gets disconnected or buffers for more than 10 seconds. This update should happen within the next few weeks.

Thanks for responding, it's nice to know it was a known issue being worked on.... As a note, we were connected over wired network with the wireless in the meetinghouses disabled.

rannthal wrote:From what I have heard, sometimes wireless systems will drop for a quick second, which for streaming can cause problems.

While this may be true, it doesn't make a lot of sense to me. Why have a 45-60 second buffer, if the slightest disruption causes the whole thing to fail?

johnshaw wrote:Thanks for responding, it's nice to know it was a known issue being worked on.... As a note, we were connected over wired network with the wireless in the meetinghouses disabled.

Ahh... you may have been speaking to the Wireless ISP we were using. In that case, my experience at my home plays that out as well. I did just learn, however, that one of our sites is now Comcast (FM doing their best to keep us all informed eh?) and not Rise. The disconnects didn't happen at the same time, but one happened on and over-the-air Wireless ISP connection and one was cable.

Mikerowaved wrote:

rannthal wrote:From what I have heard, sometimes wireless systems will drop for a quick second, which for streaming can cause problems.

While this may be true, it doesn't make a lot of sense to me. Why have a 45-60 second buffer, if the slightest disruption causes the whole thing to fail?

The problem is with reconnecting after it has been disconnected. (Which, like I mentioned previously, is being addressed with the next software version release.)

The player continually grabs more of the stream to replenish its buffer. However, if the player is disconnected from the stream, it can't grab any more. The player continues to use whats in its buffer, but will eventually run out. If the player can't get anything from the stream and the buffer is empty, there is nothing left to play.

A similar thing happens when the bandwidth drops. With the low bandwidth, the player can't download the stream chunk fast enough by the time the buffer runs out so there is nothing left to play. Thus we get buffering until the player can download the stream chunk.