I've got one PCI DVB device and two USB DVB devices. Sometimes vdr would only find one device, even though the others seemed to be working OK. I've now tracked down why.
vdr starts with /dev/dvb/adapterX/frontend0 where X = 0, increments X until it can't access the device, and then stops looking. This is probably the right way to do this but occasionally, I end up with the following devices:
/dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/frontend3
I have yet to work out what causes this but I'm pretty sure it has to do with the USB driver and hotplug which somehow manages to load and unload the USB drivers several times in succession! Unplugging the USB devices and rebooting sorts them back to how they should be, i.e. 0-2 but it's a pain if I don't notice and I end up with lots of timer conflicts because only one device has been found.
Obviously, this is a broken driver issue and vdr isn't really at fault but is it worth allowing for a situation where a device may be 'missing' in the sequence? Is there any simple way of determining how many devices have been discovered, apart from looking in the log output, e.g. could this info be added to the STAT SVDRP command or similar?
I doubt this is a common issue and I'm not really after a fix: just thought others might find the info useful!
:)
Cheers,
Laz
Laz wrote:
I've got one PCI DVB device and two USB DVB devices. Sometimes vdr would only find one device, even though the others seemed to be working OK. I've now tracked down why.
vdr starts with /dev/dvb/adapterX/frontend0 where X = 0, increments X until it can't access the device, and then stops looking. This is probably the right way to do this but occasionally, I end up with the following devices:
/dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/frontend3
Do you mean: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter2/frontend0 /dev/dvb/adapter3/frontend0
This can happen in "normal" situations too: just unplug the USB DVB adapter1.
I have yet to work out what causes this but I'm pretty sure it has to do with the USB driver and hotplug which somehow manages to load and unload the USB drivers several times in succession! Unplugging the USB devices and rebooting sorts them back to how they should be, i.e. 0-2 but it's a pain if I don't notice and I end up with lots of timer conflicts because only one device has been found.
Obviously, this is a broken driver issue and vdr isn't really at fault but is it worth allowing for a situation where a device may be 'missing' in the sequence? Is there any simple way of determining how many devices have been discovered, apart from looking in the log output, e.g. could this info be added to the STAT SVDRP command or similar?
I doubt this is a common issue and I'm not really after a fix: just thought others might find the info useful!
On Thursday 22 Jun 2006 14:23, Anssi Hannula wrote:
Laz wrote:
I've got one PCI DVB device and two USB DVB devices. Sometimes vdr would only find one device, even though the others seemed to be working OK. I've now tracked down why.
vdr starts with /dev/dvb/adapterX/frontend0 where X = 0, increments X until it can't access the device, and then stops looking. This is probably the right way to do this but occasionally, I end up with the following devices:
/dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/frontend3
Do you mean: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter2/frontend0 /dev/dvb/adapter3/frontend0
DOH! Yes, exactly that (damn cut-and-paste!).
This can happen in "normal" situations too: just unplug the USB DVB adapter1.
I'm not unplugging anything: they sometimes disconnect and reconnect themselves for no apparent reason. I don't think these USB devices (Nova-T USB2) like working together!
Actually, this may be why vdr occasionally dies when a timer starts recording. It could be trying to use a device which has now disappeared (not looked to see what checks are made when tuning a device).
Cheers,
Laz
I'm not unplugging anything: they sometimes disconnect and reconnect themselves for no apparent reason. I don't think these USB devices (Nova-T USB2) like working together!
USB devices sometimes do this, esp. with bad cabling or slightly broken hubs in between. Software handling them must be prepared for this situation (unfortunately, most isn't...)
Olaf
On Saturday 24 June 2006 21:55, Olaf Titz wrote:
I'm not unplugging anything: they sometimes disconnect and reconnect themselves for no apparent reason. I don't think these USB devices (Nova-T USB2) like working together!
USB devices sometimes do this, esp. with bad cabling or slightly broken hubs in between. Software handling them must be prepared for this situation (unfortunately, most isn't...)
This is the output I see when they disconnect and LEDs go out:
Jun 25 10:42:52 vdr-tng kernel: hub 4-0:1.0: state 7 ports 6 chg 0000 evt 0006 Jun 25 10:42:52 vdr-tng kernel: ehci_hcd 0000:00:10.3: GetStatus port 1 status 00180b POWER sig=j PEC CSC CONNECT Jun 25 10:42:52 vdr-tng kernel: hub 4-0:1.0: port 1, status 0501, change 0003, 480 Mb/s Jun 25 10:42:52 vdr-tng kernel: usb 4-1: USB disconnect, address 2 Jun 25 10:42:52 vdr-tng kernel: usb 4-1: usb_disable_device nuking all URBs Jun 25 10:42:52 vdr-tng kernel: ehci_hcd 0000:00:10.3: shutdown urb cb1b8860 pipe c0008200 ep1out-bulk
At this point, the LEDs are out but all of the device files are still there. Anything that tries to access them hangs nicely...
I hate USB...PCI cards tend to just work! Unfortunately, I only have one PCI slot in that system and htat already has a DVB card in it!
:(
Cheers,
Laz
-
Anssi Hannula -
Laz -
Olaf Titz