Re: [vdr] VDR needs some way to detect new tuners on runtime...
Hi, Am 20.08.2013 08:59, schrieb syrius...@no-log.org: Manuel Reimer manuel.rei...@gmx.de writes: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. I've asked in the systemd mailinglist, if there is any way to get around this: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html The result: The daemon (VDR) needs some way to detect devices while runtime. So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. Hi, You should be able to achieve this using the dynamite patch and plugin. I would definitey love to see its features merged in main vdr btw :) As a proof-of-concept I plan to rework the dynamite-patch/-plugin to extract the dynamic device discovering with udev as a patch-only-implementation. Klaus, I will not urge you to include this, but I think, if enough people will need and test it, maybe in the future we can make you think about it again. :) Even if you say that you never ever will include it, it won't keep me from writing that patch. I don't have a problem to patch my own vdr... :) My plans: - instantiate MAX_DVB_DEVICES cDvbDevice objects at startup - special adapter number -1 as not connected/installed/inactive, such a device will return, that it can't receive anything (Provides* functions etc.). - start a udev-monitor thread and listen for dvb-subsystem events of adding/removing dvb-cards - eval udev attributes on add-events if the card should have a specific device number and pass the adapter to the right cDvbDevice object, otherwise interpret the adapter number as cardindex - on removing a device, close the cDvbDevice (its file descriptors) and set it back to adapter -1 (will solve the usb problem mentioned in another mail) This all is done by dynamite at the moment and is working fine. But since dynamite was the first project to learn about udev and all the other things involved, a rewrite is always a good idea now all things are in place. Even closing the various file descriptors of the dvb devices doesn't lead to a segfault as some comments in the code mention. Additional udev will be used to enumerate the dvb devices and some udev attributes may be used to decide if a device should be used or not etc. I just have to work out how the cDvbDeviceProbe thing will fit into this - definitly the plugins must be able to handle the special adapter -1 and must be able to initialise its device aside the constructor. And there must be some kind of configuration so the plugins can be told how many cDvbDevice-derived objects each has to instantiate. But it is all solvable. I plan to release the first version of such a patch till end of september, if real life keeps calm the next weeks... :) And of course I will design it in such a way that it has to be enabled explicitly with a command line switch so that the default behaviour is not changed. Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 25.08.2013 12:23, Lars Hanisch wrote: Hi, Am 20.08.2013 08:59, schrieb syrius...@no-log.org: Manuel Reimer manuel.rei...@gmx.de writes: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. I've asked in the systemd mailinglist, if there is any way to get around this: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html The result: The daemon (VDR) needs some way to detect devices while runtime. So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. Hi, You should be able to achieve this using the dynamite patch and plugin. I would definitey love to see its features merged in main vdr btw :) As a proof-of-concept I plan to rework the dynamite-patch/-plugin to extract the dynamic device discovering with udev as a patch-only-implementation. Klaus, I will not urge you to include this, but I think, if enough people will need and test it, maybe in the future we can make you think about it again. :) Even if you say that you never ever will include it, it won't keep me from writing that patch. I don't have a problem to patch my own vdr... :) My plans: - instantiate MAX_DVB_DEVICES cDvbDevice objects at startup I don't like this. You can, of course, write whatever patch you like, but if the basic approach is to instantiate MAX_DVB_DEVICES cDvbDevice objects at startup then it is most certainly never going to be included as a core feature. Klaus - special adapter number -1 as not connected/installed/inactive, such a device will return, that it can't receive anything (Provides* functions etc.). - start a udev-monitor thread and listen for dvb-subsystem events of adding/removing dvb-cards - eval udev attributes on add-events if the card should have a specific device number and pass the adapter to the right cDvbDevice object, otherwise interpret the adapter number as cardindex - on removing a device, close the cDvbDevice (its file descriptors) and set it back to adapter -1 (will solve the usb problem mentioned in another mail) This all is done by dynamite at the moment and is working fine. But since dynamite was the first project to learn about udev and all the other things involved, a rewrite is always a good idea now all things are in place. Even closing the various file descriptors of the dvb devices doesn't lead to a segfault as some comments in the code mention. Additional udev will be used to enumerate the dvb devices and some udev attributes may be used to decide if a device should be used or not etc. I just have to work out how the cDvbDeviceProbe thing will fit into this - definitly the plugins must be able to handle the special adapter -1 and must be able to initialise its device aside the constructor. And there must be some kind of configuration so the plugins can be told how many cDvbDevice-derived objects each has to instantiate. But it is all solvable. I plan to release the first version of such a patch till end of september, if real life keeps calm the next weeks... :) And of course I will design it in such a way that it has to be enabled explicitly with a command line switch so that the default behaviour is not changed. Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
Am 25.08.2013 12:30, schrieb Klaus Schmidinger: On 25.08.2013 12:23, Lars Hanisch wrote: Hi, Am 20.08.2013 08:59, schrieb syrius...@no-log.org: Manuel Reimer manuel.rei...@gmx.de writes: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. I've asked in the systemd mailinglist, if there is any way to get around this: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html The result: The daemon (VDR) needs some way to detect devices while runtime. So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. Hi, You should be able to achieve this using the dynamite patch and plugin. I would definitey love to see its features merged in main vdr btw :) As a proof-of-concept I plan to rework the dynamite-patch/-plugin to extract the dynamic device discovering with udev as a patch-only-implementation. Klaus, I will not urge you to include this, but I think, if enough people will need and test it, maybe in the future we can make you think about it again. :) Even if you say that you never ever will include it, it won't keep me from writing that patch. I don't have a problem to patch my own vdr... :) My plans: - instantiate MAX_DVB_DEVICES cDvbDevice objects at startup I don't like this. You can, of course, write whatever patch you like, but if the basic approach is to instantiate MAX_DVB_DEVICES cDvbDevice objects at startup then it is most certainly never going to be included as a core feature. For now I haven't found another solution because several places all over the code (and also in the plugins) use the pointers from the device array. If they change during runtime (or are reset to NULL, maybe inbetween), there are a lot of problems to be expected. Therefore dynamite instantiates proxy devices and create subdevices with the real access to the hardware. But these proxy devices have its own kind of problems, so I think it's better to implement the hotplug functionality directly in cDvbDevice or even cDevice. It's just the next step on the way, it's way from perfect. I'm just curious if this setup will do better and doesn't change the API too much. :) Lars. Klaus - special adapter number -1 as not connected/installed/inactive, such a device will return, that it can't receive anything (Provides* functions etc.). - start a udev-monitor thread and listen for dvb-subsystem events of adding/removing dvb-cards - eval udev attributes on add-events if the card should have a specific device number and pass the adapter to the right cDvbDevice object, otherwise interpret the adapter number as cardindex - on removing a device, close the cDvbDevice (its file descriptors) and set it back to adapter -1 (will solve the usb problem mentioned in another mail) This all is done by dynamite at the moment and is working fine. But since dynamite was the first project to learn about udev and all the other things involved, a rewrite is always a good idea now all things are in place. Even closing the various file descriptors of the dvb devices doesn't lead to a segfault as some comments in the code mention. Additional udev will be used to enumerate the dvb devices and some udev attributes may be used to decide if a device should be used or not etc. I just have to work out how the cDvbDeviceProbe thing will fit into this - definitly the plugins must be able to handle the special adapter -1 and must be able to initialise its device aside the constructor. And there must be some kind of configuration so the plugins can be told how many cDvbDevice-derived objects each has to instantiate. But it is all solvable. I plan to release the first version of such a patch till end of september, if real life keeps calm the next weeks... :) And of course I will design it in such a way that it has to be enabled explicitly with a command line switch so that the default behaviour is not changed. Lars. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Wed, Aug 21, 2013 at 2:40 AM, cedric.dew...@telfort.nl cedric.dew...@telfort.nl wrote: 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 :-) You want to be able to start VDR without any dvb devices, right? 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. I seem to remember this type of dynamic/hotplug capability being discussed some time ago in regards to the new server/client design upgrade. If I'm remembering correctly, I believe this is already on the todo list for that upgrade. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 19.08.2013 23:19, Manuel Reimer wrote: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. There might be an easier way to get around this. I assume you load your module in the runvdr or a similar script at boot time?! Add a line like this after loading the required modules: /sbin/modprobe dvb /sbin/udevadm settle --timeout=30 then start up vdr. Everything should be fine since udevadm only returns after all actions regarding the module load are settled. Regards André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 08/20/2013 09:40 AM, André Weidemann wrote: Add a line like this after loading the required modules: /sbin/modprobe dvb /sbin/udevadm settle --timeout=30 then start up vdr. Everything should be fine since udevadm only returns after all actions regarding the module load are settled. This is *wrong*. It works on HDD drives but may fail on SSD drives as the system may boot up faster than the DVB devices need to initialize. udevadm settle only waits for the stuff, the system *currently* knows. A slow tuner may be found after udevadm settle. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 19.08.2013 23:19, Manuel Reimer wrote: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. I've asked in the systemd mailinglist, if there is any way to get around this: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html The result: The daemon (VDR) needs some way to detect devices while runtime. So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. Besides, VDR assumes that all devices are there when it starts, mostly because some configuration details (like device bonding or DiSEqC) rely on the fact that the devices appear in a given, reproducible sequence. udev rules can be used to assign particular adapter numbers to the devices. Maybe there is also some mechanism to make it wait until all devices have been initialized. As a very simple approach something like NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. So how could an alternative approach look like? Maybe it could work with inotify to see when new devices are added below /dev, but I think this will also require new dependencies. The easiest way may be: Call the existing code for finding the tuners not only once but every X seconds. NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. 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? Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 20.08.2013 10:20, Manuel Reimer wrote: On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. So how could an alternative approach look like? Maybe it could work with inotify to see when new devices are added below /dev, but I think this will also require new dependencies. The easiest way may be: Call the existing code for finding the tuners not only once but every X seconds. NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. 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? As I wrote before, VDR needs all devices to be ready when it starts, otherwise any configuration parameters that refer to device numbers might not work. So I guess you'll have to figure out some way of waiting for all devices to be ready before starting VDR. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Tue, 20 Aug 2013 10:12:25 +0200 Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I wouldn't like to add a dependency to libudev. Why not? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Tue, Aug 20, 2013 at 1:20 AM, Manuel Reimer manuel.rei...@gmx.de wrote: NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. 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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
