[vdr] VDR needs some way to detect new tuners on runtime...

cedric.dewijs at telfort.nl cedric.dewijs at telfort.nl
Wed Aug 21 11:40:12 CEST 2013


This works for *one* system and only if the user manually sets the number of adapters. How could this be done in a "automagic" way to allow users to just plug the tuner and reboot?


I don't think you can automate that in a very reliable way, especially if you're using usb dvb devices and/or devices with field values that aren't set correctly. The only reliable way is to have the user define how many dvb devices are expected to init, and then wait for that to happen during boot. Something like:


dvbcount=3
until (($dvbcount == $(ls -d /dev/dvb/adapter* |wc -l))); do sleep 1; done

Additionally I would add a timeout if you plan on doing this during boot:


dvbcount=3
timeout=60
until (($dvbcount == $(ls -d /dev/dvb/adapter* |wc -l) || timeout == 0)); do sleep 1; ((timeout--)); done



Hi All,

I have 3 USB receivers. Sometimes my cat runs over the cables, and in some cases causes one receiver to be loose. I would like VDR to be able to start in that situation, and not wait until all adapters are connected. This would mean I won't be able to record -and even worse watch- anything until I figure out the receiver is loose. I know I should guard my receivers so they don't go loose, but this is not always as easy as it sounds :-)

A bit offtopic, but related is the following situation: When VDR is recording something from my USB DVB-T receiver, and I unplug it, this USB port does not work anymore until the program that is using the receiver is stopped. In this situation, I would like VDR to recognize something is wrong, and stop using the receiver. Then the kernel can de-initialize the receiver, and when I re-plug the receiver, the kernel can initialize it again. Then It would be nice if VDR recognises the new receiver, and starts using it.

Best regards,
Cedric
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20130821/2b35c268/attachment.html>


More information about the vdr mailing list