I’d like to thank all of you who commented or emailed about the SiliconDust HDHomerun Connect Quatro review posted in November of last year. I’m truly amazed at the amount of interest it garnered.
And there’s some great news for those of you who have the Quatro or been on the fence about getting one – the issue reported in that review has been addressed with the 20180327 firmware!
The HDHR5 Quatro now performs on par with the HDHR4 Connect. In fact, for certain types of impairments, it may perform a bit better.
What’s Fixed
The 20180327 firmware addresses the issue with transient RF impairments. This is important since the possibility of concealing a reception error during playback is related to the amount of damage the compressed bitstream sustained.
For more on error concealment have a look at this post.
Recap: Transient RF Impairments
To recap the primary issue raised in the November post, the Quatro had a tendency to drop a large number of transport packets when a transient RF impairment occurred. A transient impairment is a very brief disturbance in the broadcast that may be caused by, for example, flicking a light switch or a bath fan (these can cause inductive surges). They may also be caused by objects somewhere between you and the broadcast tower, such as a plane or tree.
When one of these transients occur, a few to a few dozen transport packets may be affected. On the whole the damage is not extreme – in fact due to the way that ATSC is data randomized, it’s often the case many of the bits in each packet are good. Odds are that error concealment can significantly mitigate the visual artifacts caused by a transient impairment.
The issue with the early Quatro firmware, however, was that it would drop an excessive number of packets. While the fourth-generation HDHR4 would emit up to a few dozen error’d packets and recover, the Quatro would emit a few error’d packets, then stop emitting packets for a while. Analyzing a number of transport stream captures suggests that the Quatro would recover at an ATSC data field boundary. These boundaries occur every 312 packets, so if you’re unlucky and the impairment happened at the beginning of a data field, you could lose the entire field.
With the 20180327 firmware, the HDHR5 Quatro behaves the same as the HDHR4: packets which could not be successfully demodulated or error corrected are emitted with the Transport Error Indicator bit set in the transport packet. No extra packets are dropped. The HDHR5 now recovers at roughly the same point where the HDHR4 does.
While testing the new firmware it was also observed that the HDHR5 may be resilient to some transient impairments that cause the HDHR4 to emit a few error’d packets. At first I thought this might be due to cabling. When the signal becomes marginal, a slight difference in cable quality can push a demodulator over the edge. However the HDHR5’s apparent robustness survived a cable swap between the HDHR4 and HDHR5. This needs to be looked into further to see if it is consistent across HDHR5s. (I’ve also observed similar slight differences in performance among the various HDHR4s I have. The difference can’t be explained by cabling or power supplies, and may simply result from manufacturing tolerances.)
Equally important is that at no time during evaluation of the new firmware was there an instance where the HDHR5 performed worse than the HDHR4.
Recap: Weak Signal Test
The purpose of the weak signal test was to see when the HDHR5 would unlock from a weak signal by progressively attenuating the signal. It turned out that the HDHR5 was more or less on par with the HDHR4 – it appeared to unlock with just a tad less attenuation.
What was more concerning at the time was that as the attenuation was just before hitting the unlock attenuation, the HDHR5 would stop emitting packets for an extended period (hundreds of milliseconds). Now this is a terribly weak signal and we’re deliberately pushing things to a point where the demodulator will have a very rough time making sense of the signal. However while the HDHR4 emitted packets (many of them with the TEI bit set), the HDHR5 emitted none.
A more thorough investigation with real broadcasts suggests that this is more a difference in behavior between the Panasonic demodulator in the HDHR4 and the MxL692 in the HDHR5. With the 20180327 firmware, the range of dropped packets correlates well with the range of packets that the HDHR4 emits with TEI set. The damage is extensive enough that it would be the rare exception that error concealment could make use of the correctly received bits. So while it sounds bad that HDHR5 stopped emitting packets, in these cases it has no practical effect.
Summary
With the release of the 20180327 firmware, the HDHR5 Connect Quatro’s performance meets or exceeds that of its predecessors. It has begun taking the place of HDHR4s in Koherence’s projects and is recommended for anyone looking for a network-connected OTA receiver.
This is exciting news! Thanks for perhaps the only (?) site that is giving technical attention to the HDhomerun connect Quatro.
I’m a longtime fan of HDhomerun products, with long term good success with HDhomerun Prime. For me, its a workhorse and runs 24×7.
The Quatro? Aside from error performance (which now sounds promising) I’ve had problems with the device staying available.
The first unit periodically went silent at unpredictable times, requiring a power cycle to bring it back online. When it was silent the web interface wasn’t responding at all. Not really reassuring if using it to drive a DVR.. I think the green network light stayed lit but that’s about all. I tried to narrow the trigger events down to load but didn’t see a consistent correlation for 1, 2, 3 or 4 streams left running. As you mention, it doesn’t get too hot.
After returning it for exchange, got a replacement that did exactly the same thing. Until a firmware update was applied (February?). Now, instead of going completely silent it appeared to reboot periodically, as though some watchdog triggered.
That’s also not good unless your client knows to reconnect (vlc doesn’t). The prime doesn’t spontaneously reboot.
Got the 20180327 firmware update and didn’t really notice a big difference in behavior on this issue. But recently, I went to check its status and found it offline. This time permanently – it was bricked. Power cycle didn’t help and network was red light solid.
This one is going back for exchange now to try again. A little hard to believe 2 bad hardware. Sounds to me like the firmware can get stuck and the Feb release just reset it.
Note: no power or network issues correlate with the above. The Quatro, of course, has an antenna that could be affected by storms but no correlation observed there either. The antenna is indoors next to a window.
I have three Quatros and so far I haven’t seen the same issues regarding the boxes hanging. I’ve used them with the original stock firmware and various firmwares up to the current 20180327. I can image a couple things that could be affect different setups differently though. One would of course be some property of the OTA signal that I simply don’t encounter. There are a great many different types of impairments and its possible that one tickles the demodulator in an unfortunate way. In that case the HDHomerun should still respond, but it might not stream anything. One way to check it would be to use the hdomerun_config command to try to inquire about the tuner status. If it says there’s a signal lock and signal strength and symbol quality look good, then something is definitely awry. You could also be running into a problem similar to the one that occurred with the early firmwares where the tuner/demodulator had to be tuned twice in order to lock onto the signal. This was fixed in the December firmware I believe. In that case, after the first time the Quatro would report that there was no signal lock (and of course wouldn’t stream anything). In the SF Bay Area there was one channel I ran into with this property, but the others I would regularly test against were fine. Aside from some signal property it’s also possible that something could be going on with the network. In particular if for some odd reason the Quatro is getting different IP addresses and your router uses short leases. Normally the Quatro should be getting the same addresses. However I’ve run into a problem periodically where I’d reboot my router (which acts as the DHCP server for my network), and hours later all the HDHomeruns would start changing their IP addresses as they renewed their leases. This of course would give Project Entangle a bit of heartburn, although it does have some logic that eventually kicks in and forces rediscovery (that kicks in after 5s after Project Entangle notices an HDHomerun has stopped sending data, so I lose 5s or programming. Usually not a catastrophe, but certainly annoying).
The only odd problem I haven’t fully looked into is that I have a secondary setup where the Entangle, two Quatros and a HDHR4-2 Connect were on a gigabit switch. Also connected to the switch was a 100 Mbit router. For whatever reason I encountered a lot of network errors (i.e. the data was being dropped between the HDHomeruns and the Entangle). When I remove the router from the gigabit switch and connected it to the Entangle using a USB-Ethernet dongle the network errors went away. It’s as if periodically the data was being routed through the router, which being 100 Mbit didn’t have the capacity to handle the load going to the Entangle, rather then staying in the switch. Even in that case all the Quatros were stable, however.
I hope you’re able to resolve the Quatro issues. They really have matured into great performers in my setups.
Thanks for the detailed reply about the performance of your impressive setup!
A couple of clarifications, with some hopeful good news.
1 — Up until the 2nd one bricking, the boxes were disappearing from the network when they die (until power cycle) or with later firmware, simply rebooting themselves. So not moving around with different IP’s, they always came back with the same one.
In the reboot case it closed all the connections and reported itself ready for new business. Rinse and repeat. The ‘system log’ showed the random date and time when the reboot occurred.
2 — The (now) 3rd box is up and running with 20180327, 24×7 with all 4 tuners feeding VLC (same test case I was giving the 2nd box near the end). After a couple of days, no hangs or system reboots. I’m not sure this is a record yet but getting close.
The only thing I’ve found is the odd case where one of the streams just stops for some reason, leaving the affected tuner idle when later checked. I’m guessing a momentary signal issue and a dropped connection (VLC doesnt retry) but hard to tell since no one was watching. At least one of the channels did show occasional block errors on the screen.
Interestingly, one such incident happened with the HDHomerun client (rather than VLC), which doesn’t make a lot of sense. I’d expect that to retry on signal loss. Definitely the HDHomerun client program (on WIndows 10) exited, thus explaining the idle tuner. Maybe a bug with the client.
But good to hear this may not be a systemic issue with the product despite its happening on two units.
Third time is the charm. A couple of final comments
1) VLC long term streaming with HDHomeRun is a questionable practice.
I’ve had a few unprompted disconnects over the course of days of streaming. For example, if there were 4 instances running, one for each Quatro tuner, the next day one or two of them might be stopped. When this happens, the Quatro log reports (2 actual instances):
20180421-08:02:43 Tuner: tuner0 http stream ended (remote closed)
20180421-11:01:22 Tuner: tuner1 http stream ended (remote closed)
In this example, the other two VLC streams are still playing. If I launch VLC again, it also displays an error message about exiting. I added VLC logging but it hasn’t happened again to capture since using the approach below.
In any case, the disconnect problem doesn’t point at HDhomerun anymore. This unit is not rebooting after days of continuous operation.
2) In an attempt to isolate the disconnects, replaced VLC (Windows 10 v2.2.6) with cygwin wget (bonus: wget default is to reconnect on momentary disconnect). Then use VLC to play the recorded file, just behind the live point (so still appears to be streaming).
This works better than long term streaming, but leaves me with four giant ever growing files. Interestingly, VLC doesn’t like to rewind and ffwd in this file when it becomes massive (at the moment, 80, 93, 81 and 74 GB respectively).
So I am close to concluding that this 3rd unit is working.
Hope no one else is as unlucky as I was in the Quatro lottery.
Their service was pretty good, but it was getting old shipping intermittent or failed units.