Tech Forum

We had a disaster at one meetinghouse this morning because of their poor Internet service. Is there any way to set the receiving site to not attempt to go above the available bandwidth, even when it is very slow?

We would prefer pixels and video drop out, with audio remaining, rather than have the system push the Internet connection, buffer, repeat sentences, then jump ahead and skip sentences. I guess that the red B on the graph means buffering. The sixteen of them correspond quite nicely to the jumps and skips they had this morning.

The event code was 66645 and the initials of the receiving location operator used to stream the broadcast are JMM if you would like to look at the logs for the actual laptop that was connected to the projector.

We'll get into how to connect to the real event location another day, but if that would have made a difference in broadcast quality, that would be good know. And maybe we were just a hopeless cause with a 750k internet connection. But we have done it before without this much trouble using the old system. (The FM Group is beating up the ISP, but there are not any other inexpensive options at this location.)

Thanks for your suggestions.

lajackson,

My first question is did you turn the WIFI off at the building during the webcasting? If not, then that needs to be turned off. Also, remove anything that can cause things to be downloaded, such as the clerk computers, family history computers and so forth. The bandwidth should only be dedicated to webcasting. Also don't use wireless at any time for webcasting. it should all be hardwired.

If you can upgrade the bandwidth, great, but as I have found in my current job, that the more bandwidth that you are giving the users will use it up. So the first paragraph is what needs to be done to improve webcasting performance.

Terry

harddrive wrote:My first question is did you turn the WIFI off at the building during the webcasting?

Yes. There was one laptop connected to the internet at the building, the one streaming the broadcast. No WiFi, all other hard-wired connections disconnected.

Ok, I would assume that you were using the preferred player and not silver light? I have read stories on these forums that indicated that silver light has been a problem. The new flash player is much better.

After that the only other thing is to lower the quality being sent from the stake center to find a stable resolution and speed. The other option would be switch to PVC.

harddrive wrote:After that the only other thing is to lower the quality being sent from the stake center to find a stable resolution and speed.

The old system wouldn't translate speed. I think the new one does.

750K sounds real slow - and the ISP may not be able to maintain that speed during the whole broadcast.

harddrive wrote:Ok, I would assume that you were using the preferred player and not silver light?

Yes.

harddrive wrote:After that the only other thing is to lower the quality being sent from the stake center to find a stable resolution and speed. The other option would be switch to PVC.

So the Salt Lake servers do not truly compensate for slower Internet receiving speeds as we were told they did? We didn't want to penalize the other receiving locations because of this one meetinghouse. We thought the new system allowed for that.

russellhltn wrote:750K sounds real slow - and the ISP may not be able to maintain that speed during the whole broadcast.

It is the ISP's slowest speed. We are trying to bump it up to 1.5M or 2M, but it seems to regress just before each conference weekend. There are other issues with the FM Group, the ISP, payments, etc., that are being worked. I am just trying to figure out the technical end with the resources I have available.

The Portal logs are pretty revealing, and yes, the ISP did not provide even 500k during some parts of the morning. But if the Portal has streamed at 500k instead of trying to jump up to 1.5M every five minutes, we would have had a much cleaner experience for the members there who cannot fit into the stake center for conference (by intentional Church architectural design).

The current HTML 5/flash player currently has some difficulty with slower Internet speeds and adaptability. We are working to fix this issue with the player and is a top priority. For those who experience slow Internet speeds, there is a way to set the receive player to only receive at a certain speed. This, however, disables the adaptability of the player. The draw back is if the speed improves, the player stays at that speed, but if the speed drops below, the player can fail and not recover and a restart is required. If however a low speed can be sustained, this may be an option for you. Please email me if you think this may work for those of you at lower speeds and are having problems.

Is there no way to set a "ceiling" on the speed - to remain adaptable but never try to go above a certain speed?

The obvious answer is to get better Internet service. But I did IM you, rannthal, in case that doesn't happen before our next conference.

I would have told them not to try and broadcast this time, but there is not enough room in the other buildings to absorb the folks who attended at this one.

It seems that the system did correctly determine what bandwidth was available. As russellhltn said, if there were a way for it to not try so hard to go above that bandwidth, I think things would have been much better.

Then again, when you look at the graph and logs, we may have had a hopeless situation anyway.