A plea for a dedicated streaming receiver
Posted: Mon Apr 11, 2016 11:46 am
We have been very grateful to see the improvements in the web portal for our stake conference webcasts. Our webcast yesterday went very well and it was the first time we've not seen some form of disruption in the feed.
However, I also share the sentiment that we feel like we're running an experiment every time we do a webcast. Even though we met a standard yesterday, it feels like we just barely cleared the bar and we want a lot more margin. We've finally gotten to the point where the broadcast side feels pretty much under control, and the weak link now is the laptop or any general purpose computer on the receive side.
We would really, really like to have a Roku or Apple TV, or any one of a number of different dedicated streaming receivers on the receive end of our broadcast.
Don't get me wrong, laptops and computers are great for doing lots of things. I've designed lots of microprocessors for Intel and don't want folks to stop buying them. Lots of focus goes into graphics performance, throughput, etc. But, that's not the problem we need solved at the receive end. What we need is direct focus on converting a media stream into a video and audio presentation for a congregation. Updates to the operating system, virus scans, etc. have disrupted us all. And the problem actually gets worse if you dedicate a system to this function since one only turns the system on when a broadcast is coming up, only to wait sometimes an extended period of time until all the system updates are installed and working again. Personal laptops have fewer update issues, but also run into IT department restrictions and requirements. The result is often a "cross-your-fingers-and-hope-we-can-get-it-working-with-another-laptop-in-the-bag-for-backup" mentality. Plus, these things are expensive.
Why isn't this easy enough for any member who can plug in a few cables and run a remote control to set up? In this case simplicity gives reliability also because these system are designed for only one purpose.
Roku and Apple TV are great systems. They rarely fail and do a fantastic job of rendering images that laptops often choke on. With such high reliability the need for constant monitoring diminishes dramatically. Our webcast system should support these directly. Getting a dedicated channel for a Roku is an inexpensive and simple thing. Many, many streaming services do this already, often for Sunday broadcasts from a variety of churches. They have the same 2Mb limitation and still get a great picture with literally no hassle.
Okay, so these systems only allow monitoring connections and download speeds to each receiver. The simple question is whether you really need more. I would gladly trade off high reliability on the receive end for any alert/warning we've received on the broadcast end. Most of these are false positives anyway. They are much more suited to a corporate webcast system where the controllers can actually do something about a disruption or limitation. Let's face it, the only thing we do when we see an alert is worry. The real action happens when we get a text from the remote site that something has failed. And, since the portal has been updated, our most frequent failures have been on laptops on the receive end.
So, my plea is for simplicity, reliability and less hair loss from stress...
For those from church HQ monitoring this, please consider this a strong user request. Frankly, I can go to any of a number of streaming services and for $50 get access to their streaming service for a month at a time with full support for Roku and without even having to schedule the webcast. We're behind the curve for sure on this.
However, I also share the sentiment that we feel like we're running an experiment every time we do a webcast. Even though we met a standard yesterday, it feels like we just barely cleared the bar and we want a lot more margin. We've finally gotten to the point where the broadcast side feels pretty much under control, and the weak link now is the laptop or any general purpose computer on the receive side.
We would really, really like to have a Roku or Apple TV, or any one of a number of different dedicated streaming receivers on the receive end of our broadcast.
Don't get me wrong, laptops and computers are great for doing lots of things. I've designed lots of microprocessors for Intel and don't want folks to stop buying them. Lots of focus goes into graphics performance, throughput, etc. But, that's not the problem we need solved at the receive end. What we need is direct focus on converting a media stream into a video and audio presentation for a congregation. Updates to the operating system, virus scans, etc. have disrupted us all. And the problem actually gets worse if you dedicate a system to this function since one only turns the system on when a broadcast is coming up, only to wait sometimes an extended period of time until all the system updates are installed and working again. Personal laptops have fewer update issues, but also run into IT department restrictions and requirements. The result is often a "cross-your-fingers-and-hope-we-can-get-it-working-with-another-laptop-in-the-bag-for-backup" mentality. Plus, these things are expensive.
Why isn't this easy enough for any member who can plug in a few cables and run a remote control to set up? In this case simplicity gives reliability also because these system are designed for only one purpose.
Roku and Apple TV are great systems. They rarely fail and do a fantastic job of rendering images that laptops often choke on. With such high reliability the need for constant monitoring diminishes dramatically. Our webcast system should support these directly. Getting a dedicated channel for a Roku is an inexpensive and simple thing. Many, many streaming services do this already, often for Sunday broadcasts from a variety of churches. They have the same 2Mb limitation and still get a great picture with literally no hassle.
Okay, so these systems only allow monitoring connections and download speeds to each receiver. The simple question is whether you really need more. I would gladly trade off high reliability on the receive end for any alert/warning we've received on the broadcast end. Most of these are false positives anyway. They are much more suited to a corporate webcast system where the controllers can actually do something about a disruption or limitation. Let's face it, the only thing we do when we see an alert is worry. The real action happens when we get a text from the remote site that something has failed. And, since the portal has been updated, our most frequent failures have been on laptops on the receive end.
So, my plea is for simplicity, reliability and less hair loss from stress...
For those from church HQ monitoring this, please consider this a strong user request. Frankly, I can go to any of a number of streaming services and for $50 get access to their streaming service for a month at a time with full support for Roku and without even having to schedule the webcast. We're behind the curve for sure on this.