Hi,

Am 20.08.2013 08:59, schrieb syrius.ml@no-log.org:

Manuel Reimer manuel.reimer@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.

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.ml@no-log.org:

...

Manuel Reimer manuel.reimer@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

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

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

On 20.08.2013 10:42, Klaus Schmidinger wrote:

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.

You say "All devices have to be there, because there can be configuration by device-number".

Me thinks, why configuration by device-number? Configuration by index isn't always the best, there could be a configuration by name/UID or something link that.

Sure you get different problems, so it's a judgement call what set of problems is the lesser evil. For e.g. where you could formerly just swap a card and it still "just worked", you then would have to configure something. BUT adding another card would not mangle the configuration regardless of the new card getting ordered before the older card or not. I think a named configuration is a requirement for proper "hotplugability", USB devices for e.g. are inherently hotplugable.

It's basically the same thing we nowadays have with networking. In the past the first found NIC was eth0. Assuming there is only 1 NIC in a computer, in the past it "just worked" when you swapped the NIC. Nowadys you have to do something, because by default udev will (re-)name it eth1 and eth0 goes MIA. BUT adding a second NIC is guranteed to not mangle eth0, even if the kernel would initially name it eth0, udev will fix that.

So there is pro/contra for index vs. name based configuration, i personally prefer name base configuration. It's usually easier to debug and behaves deterministicly. Especially as device-discoverty/-initialization is NOT guranteed to be deterministic and/or long-term stable. Which means even if something works(/is deterministic) with kernel X, there is no guarantee that X+1 with behave identical.

And when implemented with aliases like "device0" (or aliased in such a way (if possible) that current configuration files are still valid) the configuration by index would still be possible, so the user could even choose which set of problems they want (I.E. Into which foot they prefer to shoot themselves). ;-)

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

On Tue, 20 Aug 2013 10:12:25 +0200 Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:

I wouldn't like to add a dependency to libudev.

Why not?