Visibility into stream status between origin and receive site

[jonhenderson]

Assistance needed to get greater visibility into the status of streams between broadcast and receiving sites.

We're in a far flung part of the world where the nearest datacenter is a continent away in either direction (45 sec to a minute latency) and our stream reaches into several different countries (crossing national firewalls).

Although the loss of the site by site health statistics page and the loss of realtime monitoring by support for a visiting Q12 was a surprise, we're pretty comfortable with the ins and outs of broadcasting via the vidiu appliance.

Unfortunately, we're still plagued with unpredictable reception issues at the receiving sites.
With 10+ receiving sites, we always have a few browser, low bandwidth, wifi/cellular reception issues that we address with the host member, but we also consistently have sites dealing with complete loss of the stream early or midway through a session with no cause of the problem.

We chalk it up to the nature of the part of the world we are operating in and the presence of so many variables between broadcast and receiving sites, but when its a visiting Q12 and 1/3 to 1/2 end up out in the cold, we really wish we had greater visibility into whats happening to the stream enroute.

We'd love to discover that the issue is actually on the broadcast end, because we can address it, but if not, we'd really like to find some rhyme or reason behind these issues so that we can mitigate them.

A list of suggested tools or resources would be much appreciated!

[rannthal]

Really sorry for this late reply. I don't know how I missed this. Here is what I would do.

On the VidiU, the main page, there is a broadcast view. When broadcasting, you can switch the view to this. What this shows is the raw stream coming from the VidiU itself. This is what is being sent to the servers. If this stream is bad, then the whole thing will be bad.

Also something else to try: set up an event but don't encode to it. Connect your receive sites to the event. This will allow the Tab choir video to play. This video comes directly from the server. Let this video play out and see how things go. What this will tell you is what you connection is like to the media server. If the video is playing bad, then the connection is not the best. If the video stays good then the connection is good and there may be something else going on.

Try these things first and let me know how things go.

[jonhenderson]

Thank you for your reply. We've never had much luck with the broadcat view (perpetual loads/spinning wheel) and leafy in in snapshot mode. UNTIL we tried the mobile app. Works remarkably well. A little worried about one or several techs running the direct stream to their phones and potentially adding load to switches and servers.

We'll evaluate performance on both ends via the choir video stream as you suggested.
Doesn't the stream shut down automatically if it does not receive a broadcast signal for 15-30 minutes?
Is there a way to keep the on for an hour?

Thank you!

[johnshaw]

I know it goes way old school, but there is NO gurantee of ANYTHING if you have anyone other than the receiving station utilizing the internet connection at the receiving site. TURN OFF WIRELESS is step one. STEP TWO is to make sure the receiving site is using Ethernet and NOT wireless.

OK, that out of the way. When I upload I always split the signal so I have a TV showing what's going to the Vidiu. I also bring a hotspot and connect a 'receiving station' to receive the broadcast as well at my upload location. As long as that is successful I ASSUME with 30+ webcasts under my belt that it's something with the receiving side. Whether Internet, or someone's Anti-Virus going off, or whatever. I've NEVER experienced a webcast (old or new solution) that the broadcast hardware/software is the problem. It's either ON or OFF for receiving stations, meaning if the broadcast is the issue you lose 4 out of 4 streams, not 1 out of 4. If you have an issue at the receiving side you lose 1 out of 4.

One little note as well is that I've seen differences with my upload speed. While the new solution is supposed to be dynamic, I would try going down to the slowest speed for your upload to see if that affects anything as well.

I'm also assuming you've looked at the stats available from the portal itself - very good data.

If it were me I'd setup a quick little script that logs ping requests for several hours from a clerk computer to see what kind of latency you're looking at or whether the internet connection 'goes away' - If you can get to that computer, have them stay online, you can install some software temporarily like PRTG. PRTG will setup an http ping to google and will plot it...(pingplotter is free for 14 days)

I'd heavily focus on diagnosing the receiving site internet connection.

******NOTE*******
As a note, my old stake recently (April) did a Stake Conference where they had some wards come to the stake center, but the rest of the stake went to members homes, over 70 homes accessed the stream. It's not the stream... it's not the stream....

[johnshaw]

BTW this goes to developing an APP that we could use at the receiving sites. A ROKU App please, please, please....

[rannthal]

Doesn't the stream shut down automatically if it does not receive a broadcast signal for 15-30 minutes?
Is there a way to keep the on for an hour?

Yes, it does shutdown if nothing connects. All you have to do is connect once either with a receive site or the broadcast site for about 30 seconds, long enough for the system to recognize that there was a connection, and then turn it off. From there you can observe the tab choir video without worry about the system turning off.