[pvrusb2] stability of pvr usb 2 driver

[Mike Isely]

On Tue, 17 Apr 2007, Paul Webber wrote:

> A mail order company contacted me about offering a Linux htpc with Myth and
> the Hauppauge PVR USB 2.  But the problem is that with much usage the PVR
> USB 2 keep crashing with messages like this: 2007-04-17
> 13:30:03.709MPEGRec(/dev/video0) Error: select timeout.  Unplugging it
> and re-attaching
> it solves the problem.  However, they want to sell this as a consumer
> product and so it has to be 100% rock solid.  I've got the latest drivers
> built with Ubuntu.
> 
> I assume it's a driver issue, because once Myth reports this problem, I
> can't even cat the /dev/video0 anymore and have to unplug/reinsert it to get
> it going again.  I'm running on ubuntu 6.10 with the latest drivers from the
> stie.
> 
> Do you know if the drivers are supposed to be solid and stable, or if this
> is a known issue?  If the drivers aren't 100% ready for prime time yet, is
> somebody working on fixing any issues?  I'm a c++ coder, though I don't know
> anything about the code in the pvr usb2 drivers.  If these are driver bugs,
> is there somebody willing to work with me on resolving them?
> 
> Thanks

Paul:

First of all, you might not have the latest driver.  You definitely 
don't have it if the kernel you are using is older than 2.6.20.  If you 
are playing with a 2.6.21 release candidate then you have all the fixes.  
IIRC, the critical fixes should be backported to 2.6.20.x by now but I 
should go back and check to be sure.

However with all that said, there are not any recent known issues in the 
driver with a select timeout that I am aware of.  (The recent fixes have 
to do with solving some video corruption in the encoder.)  I can tell 
you that the driver itself can't "timeout" a select() - the app is doing 
that - but it is possible that the driver might not emit any data for a 
period of time if the incoming signal quality is poor enough, which 
might cause the app to give up on it.  The PVR USB2 device uses hardware 
mpeg2 encoding, and if the video digitizer isn't locked on a signal then 
there may be breaks in the bit stream to the encoder and that will cause 
the encoder to not encode anything during that interval.  That's 
completely internal to the hardware and not affected by the driver.  
You can see this just by cat'ing /dev/video0 into say, /tmp/foobar.mpg 
while doing nasty things to the incoming signal - like perhaps using 
composite in and unplugging the video cable while encoding.

I can't vouch for what mythtv might or might not do when there's a pause 
in the incoming stream long enough for it to "time out".  Try the same 
experiments with mplayer and see what the result is.  (mplayer won't 
time out; it will pause but then should more or less pick up again when 
the video signal is restored.)  The driver, if it temporarily stops 
emitting video data (for whatever reason), should resume once the 
upstream cause for the break has gone away.  I've NEVER had any 
complaints where the driver gets permanently "stuck" streaming video.  
I HAVE seen issues where there are upstream pauses and then the app 
misbehaves as a result.  For example, xawtv gives up if the video stream 
pauses for 3 seconds or longer.  But there's nothing the driver can 
really do about this since all it's doing is passing through what comes 
from the hardware and the hardware can pause under various conditions.

I've also seen issues where bad power to the device can cause it to 
crash (remember the PVR USB2 uses a poorly filtered wall-wart not the 
PC's own heavily filtered PSU).  And I've heard of problems where bad 
USB cables, a bad USB hub, or some older crappier USB controllers can 
impact the integrity of the communication to the device and thus cause 
other crashes in the hardware.  But in all those hardware-related cases 
the symptoms are different than what you are describing.

Replugging the device should not be needed to "recover" from this.  I 
wonder if instead what is really happening is that mythtv's back end is 
traveling down a bad leg of code due to the timeout, and that when you 
unplug the device then the back end gets an EOF and disassociates from 
the now dead port.  Try this instead:  Rather than unplugging the 
device, shut down the mythtv back end, ensure that it's really dead 
(e.g. no processes left hanging onto /dev/video0) then restart the back 
end.  I wonder if that might also "recover" the problem.

I have, BTW, seen mythtv back end misbehavior involving an ATSC 
receiver, where there's a break in the bit stream (for whatever reason) 
and then the back end goes into a coma or simply crashes.  In that case 
the receiver is a PCI device not USB so there's nothing to replug; the 
only recovery I've been able to do there is a restart of the back end of 
a reboot of the HTPC.  That sounds vaguely similar to what you are 
describing, and I'm positive that this is an example of mythtv not 
handling unusual but not impossible exceptional conditions very well.

  -Mike

-- 
                        |         Mike Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |