Ready to smash the Teradek Vidiu; alternatives?

For the last couple years of stake conference broadcasts, our Teradek Vidiu boxes (yes, we've tried plural) have been thorns in our sides. They are flakey and unreliable. I'm tired of constantly fighting them. In summary, I'm done with the Vidiu boxes. Can anyone recommend alternatives?


Some history:

We've tried firmware updates, not updating, and everything in between. We've tried dynamic and static IP assignments, no difference. On too many occasions we've left hundreds of members stranded in buildings without the broadcast (even though previous tests are successful).

All APs are disabled in both the transmitting and receiving locations, but inevitably the broadcast (1.1 Mbps) will drop right before conference starts, or shortly thereafter. We get it going early, but it won't last. Here is the problem (not an internet bandwidth issue):

Unable to load the user interface through a browser (we've tried Edge, IE, Firefox, and Chrome). This is on the LAN! It shows the Vidiu splash screen (so we have the correct local IP address, i.e. 192.168.109.31), but hangs indefinitely on "Loading...". Sometimes we get the message "Unable to load system settings. Teradek might need to reboot" (I paraphrased). The boxes apparently go brain dead. So we power off and completely remove all connections, wait, then reboot. Same problem, so we rinse and repeat. We can usually get the box sane within an hour after many, many reboots (which take forever).

On this link: https://support.teradek.com/hc/en-us/ar ... a-computer

We read the following: "NOTE: Some wireless networks isolate connections so that while you may receive Internet access, you can't connect to other local devices on the same network. This type of behavior -- called AP/access point isolation, client isolation, or wireless isolation -- is often seen at hotels, coffee shops, or the guest networks provided by businesses, or on mobile broadband wireless hotspots that provide a separate guest network."

I cannot find any settings on Technology Manager (tm.lds.org) regarding the blocking or access of clients on the LAN.

Thanks for any help and support.

mawhiteley wrote:We read the following: "NOTE: Some wireless networks isolate connections so that while you may receive Internet access, you can't connect to other local devices on the same network. This type of behavior -- called AP/access point isolation, client isolation, or wireless isolation -- is often seen at hotels, coffee shops, or the guest networks provided by businesses, or on mobile broadband wireless hotspots that provide a separate guest network."

If you've turned off all APs such that nothing is going through any kind of wireless, then that's not an issue.

If you're using wireless, then I'd suggest you go 100% wired before going further.

But frankly, it sounds like your unit is dying for some reason. Perhaps overheating.

russellhltn wrote:If you're using wireless, then I'd suggest you go 100% wired before going further.
But frankly, it sounds like your unit is dying for some reason. Perhaps overheating.

We are hardwired for the Vidiu and the controlling laptop, all APs are disabled. We've tried multiple units, so I was questioning the building router, but I don't see any settings that could control/prevent access to the vidiu on the LAN.

Thanks.

mawhiteley wrote:We are hardwired for the Vidiu and the controlling laptop, all APs are disabled. We've tried multiple units, so I was questioning the building router, but I don't see any settings that could control/prevent access to the vidiu on the LAN.

As long as both the laptop and the Vidiu are on the same subnet, the router is not part of the picture.

What is your upload speed, and what will your ISP support? The only speed I see mentioned is 1.1Mbps which is quite slow. You'll probably need to stay well under what the speed tests indicate the ISP supports to make sure you don't run into a upload bottleneck.

While a few people have had problems with the Vidiu, by far, the biggest complaints have been the bandwidth problems and the church servers.

russellhltn wrote:As long as both the laptop and the Vidiu are on the same subnet, the router is not part of the picture.

What is your upload speed, and what will your ISP support? The only speed I see mentioned is 1.1Mbps which is quite slow. You'll probably need to stay well under what the speed tests indicate the ISP supports to make sure you don't run into a upload bottleneck.

While a few people have had problems with the Vidiu, by far, the biggest complaints have been the bandwidth problems and the church servers.

Our biggest problem is getting the Vidiu sane where we can command/control it from the web interface, on the same hardwired subnet. They hang 90% of the time while attempting to connect. I don't know what the problem would be. I'm looking for alternative hardware.

The 1.1 Mbps is our encoder upload speed when the Vidiu does work (rare miracle, until it drops and goes brain dead for 45 minutes of power cycles). I have not run a speed test, but the cable-based high speed internet should handle that uplink to the church servers. I'll double-check next time I'm at the stake center.

Are there alternative hardware encoders supported by the church?

Thank you.

mawhiteley wrote:Are there alternative hardware encoders supported by the church?

None that I've heard of.

The fact it takes 45 minutes to get it going again suggests either that the unit overheated or that the ISP is choking your uplink and the device is going nuts trying push packets though a reluctant ISP. I don't know what your ISP offers, but around my area, it's not usual to have 11Mbit download/1Mbit upload.

Note that some ISPs will allow "bursts" at higher speed but will start throttling you on a sustained speed. Also, the actual speed the Vidiu is sending will depend on the picture. A static picture takes less bandwidth than one with motion. More motion, more bandwidth. Depending on how you have things set up, that could explain why it dies at the start of the conference.

mawhiteley wrote:
On too many occasions we've left hundreds of members stranded in buildings without the broadcast (even though previous tests are successful).

All APs are disabled in both the transmitting and receiving locations, but inevitably the broadcast (1.1 Mbps) will drop right before conference starts, or shortly thereafter. We get it going early, but it won't last.

If your statements in "green" are accurate then you probably DO have a bandwidth/connection problem, not a VidiU problem! If you can run a successful "test webcast" when the bldg is empty then the VidiU is OK.

Consider checking the following with emphasis on underlined items:
1. After you turn off all the APs - go stand under each one and see if you can still connect via wifi.
1a. Use a WiFi scanner app to look for active rogue APs in the bldg.
2. On the VidiU setup, make sure it's own internal wireless AP is turned off otherwise members devices may be attempting to connect to it when they enter the bldg.
3. On the VidiU setup, make sure the "wired" connection is the only one activated.
4. On the VidiU setup, turn off adaptive bitrate. Also turn off auto-reconnect.
5. Check any printers/copiers in the bldg to see if they have the same static IP address as the VidiU.
6. Consider the possibility that someone is plugging their laptop into a wired connection in the overflow area or other room and consuming bandwidth.
7. Make sure all other wired computers (clerk, library, FHC, etc) in the bldg are disconnected from the LAN.
8. Consider the remote possibility someone in the bldg doesn't want you to be successful. Try physically disconnecting ALL LAN cables, except the VidiU, from the main switch.
9. After checking items 1-8, test the system reliability by doing a test webcast on a Sunday during SacMtg. Don't wait for stake conference!!!!

CalS201 wrote:Consider checking the following with emphasis on underlined items:
1. After you turn off all the APs - go stand under each one and see if you can still connect via wifi.
1a. Use a WiFi scanner app to look for active rogue APs in the bldg.
2. On the VidiU setup, make sure it's own internal wireless AP is turned off otherwise members devices may be attempting to connect to it when they enter the bldg.

Good point. While TM is supposed to control all church APs, sometimes, it doesn't work. Plus, someone may have connected a rogue AP to give better coverage in a certain area.

CalS201 wrote:If your statements in "green" are accurate then you probably DO have a bandwidth/connection problem, not a VidiU problem! If you can run a successful "test webcast" when the bldg is empty then the VidiU is OK.

I understand the confusion. When the vidiu drops, there may be a bandwidth problem. However, our issue is we cannot get into the web interface to initially start or restart the broadcast. It takes 45 min. of rebooting to get into the interface. The vidiu goes brain dead a lot, nothing to do with internet bandwidth. It's on our LAN, plugged into the same switch as the computer trying to command/control it.

CalS201 wrote:Consider checking the following with emphasis on underlined items:
1. After you turn off all the APs - go stand under each one and see if you can still connect via wifi.
1a. Use a WiFi scanner app to look for active rogue APs in the bldg.
2. On the VidiU setup, make sure it's own internal wireless AP is turned off otherwise members devices may be attempting to connect to it when they enter the bldg.
3. On the VidiU setup, make sure the "wired" connection is the only one activated.
4. On the VidiU setup, turn off adaptive bitrate. Also turn off auto-reconnect.
5. Check any printers/copiers in the bldg to see if they have the same static IP address as the VidiU.
6. Consider the possibility that someone is plugging their laptop into a wired connection in the overflow area or other room and consuming bandwidth.
7. Make sure all other wired computers (clerk, library, FHC, etc) in the bldg are disconnected from the LAN.
8. Consider the remote possibility someone in the bldg doesn't want you to be successful. Try physically disconnecting ALL LAN cables, except the VidiU, from the main switch.
9. After checking items 1-8, test the system reliability by doing a test webcast on a Sunday during SacMtg. Don't wait for stake conference!!!!

Thanks for the suggestions. Sounds like we need to sweep the entire building. For example, we broadcast successfully (after an hour trying to get into the vidiu) the entire sat. evening adult session. The next morning we started the broadcast around 8:30am (conf starts at 10 am). Worked well up until 10 min. before conference started. At that point, the vidiu dropped the broadcast and the user interface hung. We couldn't restart the broadcast for another 45 min. Hundreds of members in another building were stranded. We disconnected and power cycled the vidiu many times, same with the computer and the network switch. As far as I can tell, the vidiu units are the problem child.

russellhltn wrote:The fact it takes 45 minutes to get it going again suggests either that the unit overheated or that the ISP is choking your uplink and the device is going nuts trying push packets though a reluctant ISP.

Thermal could be a factor, however, when we start our testing in the weeks leading up to conference, the vidius have not been on for months. Upon first power on, when they are still cold, it's a crapshoot whether we can get into the web user interface. No encoding has been commanded (since we can't get into the interface), so the ISP is not a factor initially. This brain dead behavior doesn't seem to change whether the units are cold or hot.

Thanks again for your suggestions.

You might want to assign a static IP to the device. I think the current firewalls are pretty good about assigning IPs for a reasonable period of time (a day) but the old ones would assign for an hour. Having an IP change on you wouldn't be fun. The IP you mentioned in your first post is in the middle of the DHCP pool.

If the unit is acting odd when cold like that, I'd start checking settings and looking at the video that's being fed to it. If the video is a little odd or not in agreement with the settings, I could see that driving the unit batty. From what I've heard, the video converter from SD to HDMI that was recommended at one time was pretty cheesy.

The Teradek is a $600-700 unit. I'm not sure of the model, but that brand tends to have 4 star ratings. It's not something ordered off of eBay or Alibaba. Getting things set up can be challenging, but it shouldn't be that bad.

mawhiteley wrote:
The vidiu goes brain dead a lot, nothing to do with internet bandwidth. It's on our LAN, plugged into the same switch as the computer trying to command/control it.

Did you add a switch to the network? Is it just a switch or a router/switch?
Are you connected through RJ45 in chapel overflow, RJ45 on wall in AV room, or RJ45 on front of EmTech AV Rack in AV room?

Have you tryed operating the VidiU on your home network (with DHCP addressing and correct subnet mask)?

CalS201 wrote:Have you tryed operating the VidiU on your home network (with DHCP addressing and correct subnet mask)?

This was going to be my suggestion also. Try it either at home or another building. It would be good to rule out weird stuff going on with your stake center's LAN.

Mikerowaved wrote:

CalS201 wrote:Have you tryed operating the VidiU on your home network (with DHCP addressing and correct subnet mask)?

This was going to be my suggestion also.

I agree. If nothing else, it makes it less of a hassle to mess with.

mawhiteley wrote:However, our issue is we cannot get into the web interface to initially start or restart the broadcast. It takes 45 min. of rebooting to get into the interface. The vidiu goes brain dead a lot, nothing to do with internet bandwidth. It's on our LAN, plugged into the same switch as the computer trying to command/control it.

This is a little long and for what it's worth. I do not have a solution yet.

At our last stake conference, we were never able to connect to the VidiU interface. The only reason we were able to start webcasting the conference on time is because, after the last test a few days earlier, we went ahead and loaded the Sunday conference profile into the VidiU and selected it, so the VidiU was, in effect, ready to plug and play. The morning of the conference, we could never address the VidiU unit.

Because there was no interface, we were never able to see what the VidiU was encoding. The only check we had was that we have enough bandwidth at our stake center to bring down a return stream during the broadcast. We also put the receiving locations on alert to immediately notify us of any problem. If something had gone wrong, we would not have known until the end of the delay of about a minute and 10 seconds.

The only reason I let the conference webcast go that way is because of the confidence I have in the VidiU box. Even though I was effectively blind, I had had enough successful broadcasts that I trusted the box to work, even though we could not address it other than through the buttons on the front of the box, which is how we started and stopped the stream.

There is a way to enter the URL and stream codes into the box without the interface, but it is time-consuming and very painful.

The only change, to my knowledge, from the previous conference, is that the Cisco firewall was replaced with the Meraki firewall. That said, while I believe the meetinghouse network may be contributing to the problem, I am not ready to blame the problem completely on the firewall change.

Even before last stake conference, I have always had problems addressing the VidiU unit. Once it connects with the laptop, it usually stays connected. But until then, I have tried every browser on multiple laptops. It has become a little contest between my assistant and I to see who is able to make the connection first.

But while some VidiU boxes do flake and need to be replaced, I have confidence in the box itself. These identical boxes are used throughout the world in the broadcast industry. One national network has over a thousand of them feeding different broadcasts to member stations. Of note, however, I also know that that same network has a routine that reboots every VidiU on their network every night.

I have made a few feeble and unsuccessful attempts since our last stake conference to connect to and address the VidiU box. The FM Group is going to loan me another box to test and is prepared to have an extra box available for our next conference. Later this month and next if necessary, I will take the time to strip down the stake center network and see if something there is a part of the problem keeping us from connecting to the VidiU interface.

And if all else fails, I will have the first-time experience of loading the VidiU from the front panel. A lot of folks will share the pain with me if I wind up having do to that.

lajackson wrote:At our last stake conference, we were never able to connect to the VidiU interface.

I wonder if the DHCP changed the IP on you?

However, I think the main takeaway from your experience is that difficulty in connecting doesn't necessarily translate to a bad broadcast experience. We do need to be careful that we're not chasing a symptom that's not related to the real problem. (BTDT)

russellhltn wrote:I wonder if the DHCP changed the IP on you?

The first step after the VidiU is turned on the morning of conference is to get the address from the face of the box. The next step is to use the laptop to locate the box on the network. Would the DHCP change the IP address in that short amount of time?

If the VidiU gets rebooted for some reason, the address needs to be retrieved again, of course, and it usually has changed. Would anything else cause it to change (other than a firewall reboot).

If the network changes the IP for some reason while the VidiU is running, will the VidiU know it and display the new IP address, or will it still display the old IP address. My guess is that the VidiU would stop working and need to be rebooted, starting the process all over again.

lajackson wrote:

russellhltn wrote:I wonder if the DHCP changed the IP on you?

The first step after the VidiU is turned on the morning of conference is to get the address from the face of the box. The next step is to use the laptop to locate the box on the network. Would the DHCP change the IP address in that short amount of time?

That would depend on how well the Vidiu updates the display. But I'd expect it to show the address.

All in all, I think I'd assign it a static address. The new firewalls allow for that.

CalS201 wrote:Did you add a switch to the network? Is it just a switch or a router/switch?
Are you connected through RJ45 in chapel overflow, RJ45 on wall in AV room, or RJ45 on front of EmTech AV Rack in AV room?

Have you tryed operating the VidiU on your home network (with DHCP addressing and correct subnet mask)?

Thanks everyone for your suggestions and feedback. I have not done a good job separating the broadcast problems (rare) to the interface/connectivity problems (constant).

I picked up the Vidius and brought them home. I didn't have any trouble connecting to the web interface at home. While unlikely a factor, I don't allow ms windows in my home (we're a linux family). The computers at the stake center are all ms windows. Though I have tested with windows firewall and defender all disabled, no difference.

Given this home network test, it appears the brain dead behavior of the vidius is related to the network at the stake center. We have the IP address correct, 1) We pull it from the front panel interface, 2) I can ping it, 3) the Vidiu icon backdrop loads in the browser. However, after that, the "Loading" icon twirls indefinitely.

In our A/V closet, there is a single RJ45 jack. We have a 5-port netgear switch (pretty sure it's not a hub) the computer and vidiu are plugged into. The vidiu has never complained about not being "online". It checks for firmware updates every boot. Internet access must be working? While I do power cycle this box frequently during the troubleshooting, perhaps it should be replaced.

While at home, I took a number of mitigating steps:

1) Applied factory resets.
2) Turned off the vidiu WiFi router features.
3) Assigned static IPs tied to the MAC addresses for the stake center firewall (through the tm.lds.org website).
4) Assigned a password in the vidiu settings (while both our boxes have local connectivity issues, I'd say the one with the password works more often...maybe).
5) One box has the latest firmware update, and the other I have not let update (it's on 2.7.x something).

Thanks again!

russellhltn wrote:You might want to assign a static IP to the device. I think the current firewalls are pretty good about assigning IPs for a reasonable period of time (a day) but the old ones would assign for an hour. Having an IP change on you wouldn't be fun. The IP you mentioned in your first post is in the middle of the DHCP pool.

If the unit is acting odd when cold like that, I'd start checking settings and looking at the video that's being fed to it. If the video is a little odd or not in agreement with the settings, I could see that driving the unit batty. From what I've heard, the video converter from SD to HDMI that was recommended at one time was pretty cheesy.

The Teradek is a $600-700 unit. I'm not sure of the model, but that brand tends to have 4 star ratings. It's not something ordered off of eBay or Alibaba. Getting things set up can be challenging, but it shouldn't be that bad.

We have the Teradek converter from SD to HDMI. Before I was in the calling, at one conference, the audio quit working. While troubleshooting, I bypassed the audio from the Teradek converter right into the Teradek Vidiu analog in port. Guess I shouldn't have been so helpful because I'm "the guy" now. Anyway, that converter might be doing weird things. The broadcast does "look" normal when we do eventually get it working.

However, if a weird signal from the Teradek converter is causing the Vidiu to go unresponsive, that might explain why I can access the web interface at home, but not at the stake center. I'll try removing the HDMI connector from the Vidiu next time I run into this local connectivity problem.

Thanks for the tip.

mawhiteley wrote:Teradek converter

You'd think they'd play well with each other.

I'd also have a look at the cable connecting them. Apparently, there's a few different flavors of "HDMI" cables. Back when I did PA and Conference support, cables were the biggest headache.

mawhiteley wrote:
Given this [successfull] home network test, it appears the brain dead behavior of the vidius is related to the network at the stake center. We have the IP address correct, 1) We pull it from the front panel interface, 2) I can ping it, 3) the Vidiu icon backdrop loads in the browser. However, after that, the "Loading" icon twirls indefinitely.

In our A/V closet, there is a single RJ45 jack. We have a 5-port netgear switch (pretty sure it's not a hub) the computer and vidiu are plugged into. The vidiu has never complained about not being "online".

The stake center IP address range on the AV room RJ45 may NOT be what you assume (192.168.x.x) . In our AV room, the RJ45 on the wall is 10.1.x.x and the RJ45 on the EmTech rack is 192.168.x.x. You should check the DHCP address assigned to your laptop and make sure it is in the same 192.168.x.x range as the VidiU (or change the VidiU and TmManager setup from "Static" to "DHCP" - then see what address comes up on the front panel). Also, be aware that the subnet mask for the 192.168.x.x segment is 255.255.252.0 (not the typical 255.255.255.0).

There was just a new firmware version that came out, version 3.0.5. Please trying loading this version on the VidiU and see if it corrects the Web interface issues that you've been seeing. We are also trying it here in the labs.

rannthal wrote:There was just a new firmware version that came out, version 3.0.5. Please trying loading this version on the VidiU and see if it corrects the Web interface issues that you've been seeing. We are also trying it here in the labs.

Will do. Not sure when I can get to it though. Thanks!

Update on our Teradek Vidiu woes....

As previously mentioned, the unresponsive user interface is a constant problem on the stake center's network (firmware versions 3.0.3 and 2.7.x). The 2.7.x version let's us in more often than the newer 3.0.3. I plugged them into my home network, both units seemed very responsive. I was surprised.

Today, I brought both units to my local church house (not the stake center). I plugged them into a switch in the clerks office. No trouble accessing the web user interface on either unit. Tried a few reboots in between. No troubles (other than they are slow). I allowed the 3.0.3 version to update to 3.0.5. A few reboots with this latest firmware and still no troubles on that building's network. I did not attempt any broadcasting, that's a separate problem. I just need to be able to command and control them for now.

In summary, something on the stake center's network seems to conflict with these boxes, causing them to go brain dead for long periods of time. So I'm still troubleshooting.....

mawhiteley wrote:In summary, something on the stake center's network seems to conflict with these boxes, causing them to go brain dead for long periods of time. So I'm still troubleshooting.....

I know you've said you've disabled the APs, but once you turn off the APs, I'd do a check of what else is on the network. I'm wondering if one of the clerk computers has malware that's trying to spread itself and messing up your Vidiu.

I'd also have a hard look at the port and network wiring your using. Perhasp there's a bad port, cable or something of that nature. (I know from the nature of broadcasts, you're probably using the Vidiu at the same location each time.)

I think you're on the right path. Keep testing and exploring and you'll find the answer.

mawhiteley wrote:
In summary, something on the stake center's network seems to conflict with these boxes, causing them to go brain dead for long periods of time. So I'm still troubleshooting.....

I would highly recommend you confirm the DCHP assigned address of your laptop is on the 192.xxx.xxx.xxx network while plugged into the AV room jack. If its OK then take your switch, VidiU, and laptop to a different jack (clerks office) and test it there. If it doesn't work in the clerks office then you 1) have a bad switch, 2) some other device in the bldg is using the same address as the VidiU, or 3) the Vidiu static addressing is wrong (check the subnetmask, gateway address, IP address).

Mawhiteley,

I believe that you are on the right track with regards to the network at the stake center. Now one question I have for you, when you plug into the netgear switch, do you go from the computer and the Vidiu unit directly into the switch, or do you plug into the wall and then into the switch. The reason that I'm asking is because either the network cables from the devices to the switch is hosed or the switch itself has gone bad. I would suggest, if you have an available switch to replace the netgear switch and see if that solves your problem. At my stake center, I have everything plugged directly into a Cisco switch.

I would check the wiring and most definitely try another switch.

Thanks all.

While it's possible there is a hardware fault in the network wiring or the switch, I highly doubt it. Regardless, those are on my list of swap out for troubleshooting.
If there is a cable fault, the link rate negotiated with the switch would be abnormally low and/or not work at all. Neither of these are the case.

No, there is a single rj45 jack in the a/v closet. The uplink port on the switch is wired into this jack. The laptop and vidiu are connected to the switch. All devices check out IPs from the DHCP server and have no problems accessing the internet general. Also, the laptop has no problems connecting to the vidiu either (the vidiu logo back drop pops up instantly), but the loading of the user interface hangs after that point.

mawhiteley wrote:No, there is a single rj45 jack in the a/v closet. The uplink port on the switch is wired into this jack.

Color me confused. How is the uplink port different than a normal port on the switch?

We can ignore this if you're not using that jack.

mawhiteley wrote:Also, the laptop has no problems connecting to the vidiu either (the vidiu logo back drop pops up instantly), but the loading of the user interface hangs after that point.

Which makes me wonder if it isn't fending off a malware attack. The webserver can serve up the static information, but the dyamic part is being overloaded. Keep in mind that some clerks leave their machines powered up 24/7 and are typically hardwired.

russellhltn wrote:

mawhiteley wrote:No, there is a single rj45 jack in the a/v closet. The uplink port on the switch is wired into this jack.

Color me confused. How is the uplink port different than a normal port on the switch?

Network hubs often had uplink ports as well as older switches.

danpass wrote:Network hubs often had uplink ports as well as older switches.

Ok, I think that photo shows a switchable port that can go between "normal" and "crossover".

In some switches, the uplink can be a special port's designed to talk switch-to-switch, using different protocols and stuff (not just a crossover). I was trying to figure out why that port would be connected to the front of the AV rack. Especially since it still needs to connect to something "upstream" to connect to the internet.) If it's just a selectable cross-over, then I can understand it.

Well there could be packet loss, because of a bad cable or port on the switch. You said it worked fine other places, so you have narrowed it down to the stake center.

In my line of work, I have seen splash screens come up and the. It does because of a host of things. DHCP is a connectionless protocol and will generally work, but connecting to a web interface is connection based. So if the packers are malformed or being transmitted then there is a network issue.

I had a WAP that was telling me that it had an ethernet issue, so I changed the port on the switch, which btw us a Netgear 16 port switch with POE and when I changed the port, i haven't has an issue with it.

So replace the switch with a known good one and try again.

A better solution than the Teredek is Wirecast software. It is far more capable and easier to monitor and control what is going on. Take a look at the white paper I just posted (9 Nov 2018) https://tech.lds.org/forum/viewtopic.php?f=146&t=32747

There are a group of us that have recommended against using the Vidiu boxes in any case. We have found PC-based mixing/encoding systems much more reliable. Running Wirecast, vMix, or OBS (free) allows not only video and audio mixing and synchronization, but allows an intelligent streaming source also. This then opens up the possibility of using a variety of different cameras (clean HDMI, encoded IP cameras, etc.) and can stream easily to either the church system or an external webcast provider without fiddling with control interfaces. It also allows audio mixing and much better control over output levels.

Yes, it costs something, but it's much less prone to failure and avoids the really uncomfortable situation where hundreds of people are stranded waiting for the webcast to come back. Since we went this way 3-4 years ago we have increased reliability and quality to the remote locations and attendance at conference has increased.

Reliability is the name of the game. The Vidiu box is something I have only used as a backup streaming device. Computer-based is far more capable. I don't understand why Wirecast was removed from the distribution center web store. I have heard of numerous stakes having issues with the Vidiu boxes.

I've been reminded to post an update to our Vidiu woes. Sorry I haven't.

I'm still against using the boxes, and would recommend an alternative whenever possible. Otherwise, I have found *some* success by sticking to these guidelines:

1) DO NOT let the firmware update beyond 2.7 2.4.7!! At least for the router in our old stake center, there's a fundamental problem where access to the vidiu user configuration through the web interface is completely broken.

2) Manually configure the router's DHCP server to reserve IP addresses for each vidiu tied to its MAC.

Under these conditions, we were able to stream a low-resolution video broadcast without dropping throughout the ~2 hr stake conference.

Hope this helps.

bcourtenaya wrote:Take a look at the white paper I just posted (9 Nov 2018) https://tech.lds.org/forum/viewtopic.php?f=146&t=32747

Big thanks!! This write up is much appreciated.

Though disappointing you had to produce it on your own time as a service. While we have *paid*, so called professionals, working for the church, who can't provide a reliable streaming service, nor alternative solutions like yours.

mawhiteley wrote:1) DO NOT let the firmware update beyond 2.7!!

Since there doesn't appear to be a post edit button on this form, here is a correction: firmware 2.4.7.

mawhiteley wrote:Since there doesn't appear to be a post edit button on this form, here is a correction: firmware 2.4.7.

Edit it only good for a few hours. But, so as not to mislead anyone, I went back and changed it.

I'll give another big +1 for OBS Studio on a decent laptop. Works great through the Church servers and YouTube (and other streaming sites for that matter). Keep the bit rate in the range of 2 Mbps for the Church servers or they tend to break.

Did you ever resolve the issue with your VidiU? Our stake has had 1 vidiu box For the past few years and it has never been an issue, but having that box be the “go no go” reason for failure forced to be have a backup in place. Currently I use OBS for that. We have our video feed run through my computer downstream for lower thirds/graphics and then HDMI out to the vidiu. This computer is also connected to the Lan via wire. In the event that vidiu goes down, I switch to the OBS software which is running in the background and hit “start streaming.” I would say the stream is down for not more than 30 seconds.

However, doing broadcasts like I do them is not for the average member especially since we are not broadcasting sacrament meeting during Covid life. Having 2 stake conferences a year is one thing, but having 9 sacrament meetings every week is a completely different animal. I am trying to think of the simplest way possible to set up the other wards in our stake for success, but there are so many variables that it is proving difficult.

So, wondering was other STS members are doing to help non tech inclined members to successfully broadcast their sacrament meetings.

Moku

Little late to this thread, but I, too, am done with our Teradek. It has flaked on us too many times and prior to one of our recent events, after a reboot, it never came back to life. (Teradek was willing to RMA, but the device is out of warranty and will likely take a considerable fee to get it repaired.) FM lent us their backup Teradek. I asked FM for two new Teradeks - one for prod, and one to always have on hand for backup - but was told our stake would need to fund these purchases. Instead of going with more Teradek units, I will test something like this. They're about 1/4 the price and will allow us to afford two devices.

https://www.amazon.com/URayTech-Support ... 261&sr=8-3

We also had nothing but grief from our vidiu/Azure setup. It would always pass our test broadcasts, and then fail in the middle of conference. We tried everything. Then Salt Lake kindly sent us a replacement vidiu, and we switched to Youtube Live. It hasn't failed since then. We think our vidiu was overheating, or had some thermal related problem.

dcburnett wrote:We think our vidiu was overheating, or had some thermal related problem.

The couple of times I used ours it worked fine, but noticed it got pretty warm. I ended up zip-tying it to the tripod (single camera) in a vertical position to help the natural airflow.

kaaloa wrote:However, doing broadcasts like I do them is not for the average member especially since we are not broadcasting sacrament meeting during Covid life. Having 2 stake conferences a year is one thing, but having 9 sacrament meetings every week is a completely different animal. I am trying to think of the simplest way possible to set up the other wards in our stake for success, but there are so many variables that it is proving difficult.

So, wondering was other STS members are doing to help non tech inclined members to successfully broadcast their sacrament meetings.

Moku

The goal is remain simple and inexpensive (this might be a temporary solution), so using existing hardware/software options. Accordingly, our Stake has decided to have each ward call a Ward Tech Specialist(s) (WTS).

The WTS' responsibility would be Sacrament Meeting broadcasts using their smartphone and a small clamp on the podium. The service options are 1) Zoom (configured so participants cannot unmute), and 2) Facebook Live. We are leaving it up to each Ward. Youtube Live isn't feasible in most cases since a mobile device live broadcast is restricted for users unless they have 1000+ subscribers. The WTS will be trained by our STS (if needed). Afternoon lessons will be using Zoom for two-way discussions.

Other ideas?

mawhiteley wrote:Youtube Live isn't feasible in most cases since a mobile device live broadcast is restricted for users unless they have 1000+ subscribers.

The limitation is only if you use the YouTube app. If you use another app like Larix Broadcaster, then it's not an issue.

I'd also not rule out using a laptop with a webcam. It's also simple and has a number of delivery options.

russellhltn wrote:

mawhiteley wrote:I'd also not rule out using a laptop with a webcam. It's also simple and has a number of delivery options.

Right, a laptop opens up a world of possibilities. However, we're trying to be small and inconspicuous. Sacrament meetings will be attended nominally, we don't want to obstruct view of the speaker. The broadcast is for those at risk, or who otherwise are unable to attend. Thanks.

mawhiteley wrote:However, we're trying to be small and inconspicuous.

If it's an external webcam, the laptop doesn't have to be right at the podium, but along side it. As long as it's in reach of the USB cable.

There is another thread on this topic - where a J-Tech device is used. And, a firmware update was created (currently on 1.0.4) that will auto-update the config from the church webcast site. Look under this thread.