[pvrusb2] Weird behavior with my Happauge UB-PVR

[Mike Isely]

On Thu, 20 Mar 2008, Rod Smith wrote:

> On Thursday 20 March 2008 09:50:14 mailinglists at vanhlebarsoftware.com wrote:
> >
> > Normally my PVR is mounted at /dev/video0, however, frequently it will
> > change to /dev/video1 without any reason. Normally I had seen this
> > when I would shutdown the backend in order to run mythfilldatabase and
> > then restart the backend. When this does occur, from the command like
> > it looks like the backend starts, but upon review of the log file, you
> > can see an error that the backend could not read from /dev/video0 or
> > /dev/video1, depending on what I had it set to previously.
> 
> Mike is certainly more authoritative than I am in terms of causes, and if he's 
> right my suggestion might not help; however, you might want to check out the 
> following MythTV wiki entry:
> 
> http://www.mythtv.org/wiki/index.php/Device_Filenames_and_udev
> 
> It describes using udev to set up named symbolic links to your video device 
> files. The usual purpose is to help when device filenames change when you've 
> got multiple devices, but depending on the cause and other details, it might 
> just help with your problem. Certainly it's worth trying; if it doesn't help, 
> you'll have wasted some time, no  more.
> 

There's some good stuff there, but I don't think it's the problem.

What happens here with udev is roughly something like this:

1. Device is plugged in.

2. USB core tells the pvrusb2 driver that there's a new device to 
handle.  (If the pvrusb2 driver isn't loaded, it will be first located 
via USB ID and then loaded.)

3. The pvrusb2 driver initializes internal state and sets up the new 
device.  Things like firmware download happen here.

4. Once the pvrusb2 driver is happy with the hardware and has set 
everything up, it then registers itself with the V4L core.

5. The V4L core then allocates an unused minor device ID for it (unless 
you overrode this using a module option and specified a particular ID).

6. The ID is returned back to the pvrusb2 driver and udev also learns of 
the new V4L device.

7. Based on the major / minor device ID, udev creates the appropriate 
/dev entry.

8. Steps 4-7 are repeated if the device has an FM tuner (all Hauppauge 
devices do) in order for /dev/radioX to also appear.

So the entity actually deciding if it's "/dev/video0" or "/dev/video1" 
is udev but it's using the minor ID as input to this process.  You can 
certainly hack the udev configuration to change this behavior, but the 
underlying problem is that the minor ID is spontaneously changing and 
that is the problem that needs to be understood and addressed here.

The scenario which can cause the minor ID to change like this is if the 
device is rapidly unplugged then re-plugged into the host computer.  
The "rapid" part is important because there's a race here: If you plug 
the device back in before the pvrusb2 driver has finished tearing things 
down (and it can take a LONG time if an app is still trying to use the 
dead device - the driver has to wait until the app gives up), then for 
example /dev/video0 will still be allocated and thus the V4L core ends 
up allocating /dev/video1 to the new driver instance.

Power glitching can cause the PVR device to reset, and from the host 
viewpoint that will look pretty much exactly like it had been quickly 
unplugged / replugged.  A bad USB controller or a flakey cable can do 
this do.  In fact, I've had cases where all I had to do was barely touch 
an old worn-out USB cable and the loose connector there causes the same 
glitch.

Hmm, I should update the docs to talk about this...

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8