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

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Sun Aug 25 12:30:29 CEST 2013


On 25.08.2013 12:23, Lars Hanisch wrote:
> Hi,
>
> Am 20.08.2013 08:59, schrieb syrius.ml at no-log.org:
>> Manuel Reimer <manuel.reimer at 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.



More information about the vdr mailing list