[mythtv-users] Unresolved 0.27-fixes/HDPVR issues

Keith Pyle kpyle at austin.rr.com
Wed Dec 11 18:48:40 UTC 2013


On 12/10/13 22:55, Oz Dror wrote:
> It was suggested to me in a prior post that the xhci (USB3.0) driver is not
> fully mature under linux.
>
> In my observation. Although the USB 3.0 might be an issue. The other issues
> that I mentioned are more significant.
>
> I have tried all the USB ports. I almost bought a USB 2.0 PCIe card. Now
> the HDPVR is connected to  USB2.0 port. Unfortunately The Linux kernel uses
> the Xhci driver not the ehci for this port. Even if I disable the USB 3
> ports in the BIOS the kernel still uses the Xhci driver.
>
>   At this point the USB 3.0 is a minor issue. ( because I removed a USB 3.0
> HUB, I use a USB 2 port and I reset the HDPVR daily)
Oz,

Based on my own experience and frustration with the HD-PVR, I strongly 
suspect that what you're seeing is a problem between the hdpvr kernel 
module and the HD-PVR firmware.  I have had a *lot* of issues with the 
HD-PVR and none of the usual suggestions (e.g., different USB port, no 
other USB devices, different USB cable, different power supply) had any 
statistical impact on the problem over several hundred controlled 
tests.  (I reported on some of these results on this list last year.)

The HD-PVR hardware and firmware have several issues and I've identified 
three specific issues: (1) hard hang due to i2c IR polling, (2) hang due 
to unstable input, and (3) recordings start but end unexpectedly.

IR polling: I have one system where the HD-PVR would almost never run 
for more than 10 minutes without a hard hang (>90% failures in < 10 
min.)  With help from some folks I met on the linux-media list, I have 
some patches to the hdpvr kernel module and the same HD-PVR on this same 
system has had *zero* hangs in roughly six months of use.  These patches 
disable the IR receive functions in the hdpvr module.  It appears that 
the HD-PVR firmware can enter a deadlock state under some cases where 
the i2c subsystem polls the HD-PVR.  It also seems that the frequency of 
this problem is dependent on the specific system hardware.  That is, it 
may happen a lot on one mother board and rarely on another.  I suspect 
that this is exactly what you're seeing.  Unfortunately, none of us 
involved in creating these patches has had the time to get them included 
in a kernel release.

Input instability:  If the video input to the HD-PVR is unstable, the 
device may hang.  This can be caused by the resolution changing due to a 
channel change.  A related issue is closing and reopening the device too 
fast.  The HD-PVR needs a few seconds to stabilize between changes.  In 
my tests, I found a 3 second delay was the minimum needed to avoid hangs 
(2.5 seconds or less showed a tendency to hang, rate of hang inversely 
proportional to the delay).  I use a 5 second delay at the end of the 
channel change and allow this much time on closing the device before 
re-opening it (i.e., stop one recording and start the next capture).

Recordings end unexpectedly:  This one was interesting and also doesn't 
have a MythTV solution.  Over a large number of tests, I found that the 
HD-PVR will sometimes just stop capturing.  To track this down, I did 
concurrent SD recordings of the program being captured by the HD-PVR.  
In every case, I found the end of the capture coincided with a long 
black frame on the input, typically at a program/commercial transition.  
It is highly reproducible - I found one case where re-airings on a 
specific program episode would always fail and always at the same 
program/commercial transition. Some networks/program don't seem to have 
these transitions and others do, so the incidence rate varies and may 
seem random.  I've written a small C program that can capture from the 
HD-PVR, monitor for the end of data from the HD-PVR, and restart the 
capture.  With this program, I've had no "short" recordings.  This 
approach has the issue that the resulting recording is a concatenation 
of two capture streams and tools like vlc get confused about the capture 
length. Of course, MythTV wants to directly access the HD-PVR and my 
program can't be interposed.  The real solution would be to have the 
firmware fixed, but that's not likely to happen.  Next best is the make 
the hdpvr kernel module more robust and handle this problem directly.  
Again, no time to work on this one...  so I mostly record from the 
HD-PVR through scripted use of my program instead of MythTV.  It's 
clearly a less desirable solution, but has converted my HD-PVR from an 
expensive paperweight into a usable investment.

Keith


More information about the mythtv-users mailing list