| Planning | Selection | Testing | Setup | Windows | Top |
From time to time the Hauppauge HVR-950q DVB device (HDTV capture) goes catatonic, for no reason. The HVR-1950 appears to do the same thing. Some of the drivers are locked in memory and cannot be removed for a total reset. The only recourse is to reboot the host machine. The same (?) thing was particularly likely to happen if the host suspended to RAM.
Formerly the backend and DVB were on Iris and Aurora, which sleep when not in use, but to mitigate the catatonia I moved the backend and DVB to Jacinth, which never sleeps. Reliability is improved but is still not acceptable. Jacinth is the main router, and rebooting it is always a traumatic experience. I want to move the backend and DVB to another machine.
The goals for this project are
Highly reliable MythTV recording.
Low power consumption, particularly when not recording.
A feasible recovery mode when the DVB goes catatonic.
Not too much burden in system administration.
Not too much expense for new equipment.
These issues need to be evaluated to give effect to the goals:
If I were able to return to using one of the existing machines as the backend, that would have a lot of advantages in the areas of cost and administrative effort.
When the DVB goes catatonic, there is really no way (that I know) other than rebooting to reinitialize it. This means that the host must not be responsible for ongoing mission-critical tasks. My experience is that the HVR-1950 requires power to be removed from the device, and power is supplied by a separate wall wart. The HVR-950q is a conventional USB stick, and S5 state (software power off) should be enough, but I have always done S6 (remove plug for 20 seconds).
With kernel 4.1.13, the module pvrusb2 gets a null pointer dereference when you try to shut it down, for unloading, suspending (S3) or hibernating (S4). This is the keystone module for both DVB devices. With kernel 3.6.x (SuSE 13.1) there were different but equally troublesome driver issues, but with enough messing around you could get it into S3 (not S4). But with kernel 4.1.x the backend host is going to have to be on all the time.
In retrospect, I can't say with assurance that the HVR-950q on Jacinth (never sleeps) is dramatically more reliable than when it was on Iris (former kernel 3.6.x), which would sleep. We have had two failures in about 3 to 4 weeks. Iris seemed to mess up more frequently, but less than once per week. So we're going to need to be able to reboot the recording host whenever necessary, and we're going to need automated monitoring to do this before trying to record a program.
If I want a machine that never sleeps, ARM processors have lower power than Intel, and the CPU capacity needed to record TV (versus to perform it) is small. But supporting the ARM architecture is a lot of work: Rasbian would be a whole other distro, while SuSE's ARM support is likely to be weird and to lack many packages.
It is possible that a different DVB might be more reliable. But my impression (when selecting the DVB two or three years ago) is that the Hauppauge devices are the best of a bad lot.
I am getting a feel for how this deal is going down:
Initially I was thinking about getting a Raspberry Pi (ARM) for the backend. It would never sleep. (They aren't equipped to, according to forum postings, or the authors hadn't figured out the right procedure). Before recording, I would need to test the DVB, and reboot if it was hosed. I do have a tester that works.
However, insomnia turns out not to be the magic bullet that will cure the problems with the Hauppauge DVBs, and without that, the hassle of supporting the new architecture is definitely not worth it.
But a driver bug has surfaced which makes the DVB inoperable
if the host goes to sleep (S3 or S4). So we're back to the
never sleeps
requirement.
Plan B is to move the backend back to Iris. Advantages of Iris: Actually most of these apply to any of the existing machines.
Disadvantages of Iris:
Plan C is to look at other hosts. Here's a list:
| Name | Power Idle/Max | Disc Total/Avail | CPU | Chassis | Role |
|---|---|---|---|---|---|
| Aurora | 29W/43W | 250/181Gb | AMD Ath 6850e 2x 1.8GHz | Dell Insp 400HD Zino | MythTV playback |
| Diamond | 14W/30W | 500/190Gb | Intel i7 3517UE 2x 1.7GHz | FitPC Intense | Alice's desktop |
| Iris | 19W/29W | 1000/911Gb | AMD G-T56N 2x 1.6GHz | FitPC3-Pro | MythTV playback |
| Jacinth | 13W/17W | 500/142Gb | AMD G-T40E 2x 1.0GHz | FitPC3-LP | Master site + Router |
| Kermit | 12W/29W | 250/219Gb | AMD E-350 1.6GHz | Zotac Z-Box AD03BR | MythTV Backend |
| Piki | 29W/43W | 250/219Gb | AMD Ath 2650e 1x 1.6GHz | Dell Insp 400HD Zino | Audio playback |
| Xena | 30W/59W | 750/438Gb | Intel Core i7 4x 3.2GHz | Sony Vaio | Jimc's laptop |
| (New) | 5W/5W? | ? | Intel Core i3? | Intel NUC | (New) |
Of these, Kermit and the NUC are by far the most attractive. Plan C will be to put the backend on Kermit, with the NUC as a path forward if we want to get serious about power saving. Piki will return to the upstairs audio playback role.
Periodically, particularly soon before recording a show, I need to do a real functional test of the DVB, and reboot if needed.
S5 is another possibility: reboot to record a show, then power off when finished. However, this takes 1 minute. If I'm using Iris as a playback node, the WAF of this plan is going to be low.
How can the HVR-1950 be power cycled? A power saving
plug
strip, into which are plugged Iris as the master, and one wall wart as
the slave device. This arrangement worked well for Kermit in the audio
playback role, where the powered speakers needed to be turned off. It
is significantly cheaper than, e.g. a Phidget.
Originally Iris handled both the video recording and playback roles, but it was fired from recording because it uses too much power to run all the time, and sleeping messes up the DVB drivers. The NUC eventually selected has the CPU power of Iris (or maybe more) at 30% to 40% of the idle power. So I'm planning to revert to the original plan, giving the NUC both video roles, but not sleeping.
With the roles, the NUC will inherit the rotating disc, name and IPv4 address of Iris. This 1 terabyte disc was bought to hold video recordings. (The IPv6 address is derived from the MAC address and follows the chassis.)
Kermit, presently recording video, will return to audio playback, which it handled with no problems.
The present Iris will inherit the disc, name and IPv4 address of Aurora, and will take over Aurora's video playback role.
The Aurora chassis will take over the disc, name and IPv4 address of Piki, and will become a hot spare, sleeping except for updates and maintenance.
The Piki chassis will fade into oblivion.
Measuring the power used by the FitPC-Pro (under its former name Iris). These are done with a Kill-A-Watt inline power meter, with a readout resolution of 1 watt, near zero offset, and reasonably decent calibration (but not verified with objective standards). (*) indicates this includes an external fan drawing 1 watt, but not the video capture device.
Iris sleeping with the DVB (either one) connected:
It will not sleep (S3) unless you unload a lot of drivers. This is with kernel 3.x. Testing again with 4.1.13: you can't unload the drivers for the HVR-1950; pvrusb2 gets a null pointer dereference and it is the keystone for all the others. Very likely that the HVR-950q has the same issue since pvrusb2 is its keystone also.
Re-testing S3 without unloading drivers: systemctl suspend
puts it to sleep (better than kernel 3.x), and WOL wakes it right up,
but pvrusb2 gets the null pointer dereference when being shut down (by
the kernel, not jimc's cowboy programming) before S3. After waking,
pvrusb2 recognizes the HVR-1950, but in the functional test dvbv5-zap
gets an I/O error.
S3 cannot be used with kernel 4.1.13 when the HVR-1950 (and probably the 950q) is connected.
S4: Needs to be tested. Preliminary tests failed with kernel 3.x,
DVB was not reinitialized. Testing again with kernel 4.1.13, without
unloading drivers. systemctl hibernate
takes about 30 secs to
go down, and also about 30 secs to wake (by WOL). But it gets the
null pointer dereference and the device fails the functional test the
same way, I/O error. So S4 is still not useable.
S5: Always works :-) Normally Kermit takes under 10 seconds to power itself off (with a hosed DVB), but one time when the DVB was hosed it took fully 2 minutes to go down. It will wake on RTC. It takes about 80 seconds to boot, counting to when the network is up; starting all services would take about 30 secs more. The DVB is again functional once the host comes up.
The smart power
plug strip does kill power to the DVB,
which is functional when the machine comes back up. You have to adjust
it according to the power drawn by the host.
To wake some time in the future, echo 0 > /sys/class/rtc/rtc0/wakealarm; then echo e.g. +60 to wake 60 seconds in the future. If the machine takes a long time to go down, the alarm might fire while the machine is still up. It is believed (but not actually tested) that waking on RTC is equally reliable if you set it this way, compared to giving an absolute time to wake. The FitPC-Pro was reliable at waking, but the Zino 400HD missed wakeups too often, and a supplementary Wake on LAN was deemed advisable.
If the HVR-1950 is powered off, it sets off the null pointer dereference in pvrusb2. So if one of the DVBs is disconnected to save power, the host should be rebooted.
Wiki page on linuxtv.org about the Hauppauge WinTV-HVR-1900 (uses the same firmware as the HVR-1950).
With the HVR-1950 newly plugged in, when Iris wakes it loads:
xhci_hcd pvrusb2 tveeprom cx2341x dvb_core v4l2_common videodev.
HVR-1950 USB ID is 2040:7501, product description WinTV HVR-1950 Model
751xx
.
Oops, firmware seems to be missing. It wants these firmware files:
The wiki page has links for the first two. Download the files and copy them to /lib/firmware/. The third one is in the ivtv-utils (Ubuntu) or ivtv-firmware (Gentoo) packages. On the SuSE Build Service it is called ivtv-firmware and is a sub-package of ivtv; it is not free software. Once you have all three files installed, reboot the host (Iris).
What is a good package for testing the DVB? ~watchtv/bin/dvb-check has this already set up. Takes about 10 secs if failing, 3 secs if it's going to work. The script was updated to use dvbv5-zap rather than azap and femon (obsolete).
customer infraredbuilt in. No need for separate dongle.
| Planning | Selection | Testing | Setup | Windows | Top |