Re: VDR needs some way to detect new tuners on runtime...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25.08.2013 12:23, Lars Hanisch wrote:
Hi,

Am 20.08.2013 08:59, schrieb syrius.ml@xxxxxxxxxx:
Manuel Reimer <manuel.reimer@xxxxxx> 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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr




[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux