[ANNOUNCE] dynamite plugin

  Hi,

Some friends asked me to modify vdr/write a plugin, because their boxes boot so fast that most of the hardware is not 
initialized by the time vdr can start. They had to delay it or had to restart vdr when they think the hardware is ready. 
But since some pci-cards are 'fast enough' they would like to attach the 'slow' cards later while using the 'fast' cards 
for watching, recording etc. as soon as possible.
So 'dynamite' was born (just some kind of wordplay with 'dynamic' and it sounds more 'bombastic' and effective in 
advertising than 'dyndev' or whatever). :-)

It's clear that this can't be done without patching the device handling inside vdr, so attached is my patch against vdr 
1.7.17. It is designed in such a way that the original behaviour of vdr is not changed if the dynamite plugin is not loaded.
I know that it is pretty invasive but it is as small as I could to do it. My knowledge of the inner relations of the 
various classes is certainly limited but I spent hours and hours on reading the source. And it is tested by a brave crew 
of volunteers. Nonetheless I would like to hear some remarks from the vdr-experts out there.

In the following lines I will try to explain what this patch-plugin-combination is able to do and how it's done. It's a 
bit lengthy but it's important to me and I know it wouldn't get integrated at all if I don't give a wider overview about 
the concepts and ideas behind this.

Features:
- attach/detach devices
While vdr is running you can dynamically attach/detach (unused) receiving devices to/from it.
This could be a DVB-USB-stick or a very slow initialising piece of hardware (firmware load etc.).

New devices are detected via udev, detaching should be made manually. If a frontend is in use udev is not sending a 
corresponding signal, there are just some messages from the usb subsystem, for example. The mapping to the right 
frontend and detaching it automatically is not trivial (in other words: it's on the TODO list).
Also OSD integration is completely missing but will be added in the future.

For attaching/detaching there are SVDRP commands (and Service calls for other plugins):
PLUG dynamite ATTD /dev/dvb/adapter0/frontend0
PLUG dynamite DETD /dev/dvb/adapter0/frontend0

For a complete list of commands please read the README[1].

- set device on idle
You can set a device to 'idle' mode. It will be ignored by the EIT scanner and closes all its handles.
This is handy if you have enough tuners and want so save some power or preserve some frontends from being 'always on'. 
This is also a 'manual' feature, some kind of automatism is planned (some kind of timeout or similar).
Of course it will be 'reanimated' automatically if a recording is starting or someone wants to look live-tv.

- GetTSPacket timeout
It is possible to set a 'GetTSPacket' timeout on the devices. If a device delivers no data for some time it can be 
automatically detached. This is intended for devices which has known unstable drivers. After detaching such a device a 
script is started so the driver can be reloaded and the device can be attached again to the vdr (this could happen on 
its own if the created frontend is signaled by udev).
It avoids restarts of vdr and interrupting recordings on other devices.

How this all is achieved:
The class cDevice is extended by two fields: parentDevice and subDevice.
The dynamite plugin provides a class derived from cDevice which passes all calls to its methods to its subDevice if one 
is attached. Otherwise it returns the appropriate values so vdr does think it can't receive anything (like the 
dummydevice output-plugin which can play everything).
On the other side there are some methods in cDevice which have to be "parentDevice-aware", since they are called from 
other derived devices or classes inside vdr. Since parentDevice (and subDevice) are always NULL if dynamite isn't 
loaded, it's easy to preserve the original behaviour.

To get the cDynamicDevice between the vdr and the device-creating plugins dynamite is doing two things:
- it registers a cDvbDeviceProbe-object and moves it to the front of the list
- the patch adds a second list 'cDynamicDeviceProbe' for 'dynamite-aware' plugins (like pvrinput as an example)

On startup when vdr iterates through the dvb-devices dynamite captures all devices and adds a cDynamicDevice for every 
one to the global vdr-device-array. It asks all other cDvbDeviceProbes if they would like to create a device and 
attaches this as a subDevice. If no cDvbDeviceProbe is left it creates a core cDvbDevice on its own.
After this it creates enough cDynamicDevice objects to flood the vdr-device-array. This ensures that vdr and other 
plugins always communicate with the devices through dynamite (like CAM, CI etc.) and so there is enough room for devices 
which will be attached later.
If you use plugins which create (non-dvb-)devices which can't be handled by dynamite (like xine, iptv, streamdev etc.) 
they have to be loaded *before* dynamite. Actually it's best to load dynamite as the *last* plugin because then it can 
ensure that its cDvbDeviceProbe will be the first one.
The dirtiest part of the patch is the modification of the constructor of cDevice. If the new 'parentDevice' parameter 
would be made non-optional, I don't have to use this ugly global placeholder... If it really gets integrated in vdr (I 
don't abandon hope on this), that would definitly gets cleaned up. But that would force changes on many plugins so I 
chose 'the dirty way'.

Plugins which would like to use the functionallity of dynamite had to alter their device detection in their startup phase:
- if dynamite is loaded just register a cDynamicDeviceProbe object and use the helper function QueueDynamicDeviceCommand 
from cDynamicDeviceProbe to queue the strings it needs to create the device objects.
- if dynamite is not present create the devices like before
- make sure you close all handles on destruction at the latest

Look at pvrinput[3] as an example (cPvrDevice::Initialize at device.c:269 and at the end of that file)
pvrinput uses strings like '/dev/video0' to identify the device it has to create. But these 'attach'-strings doesn't 
necessarily need to be real device paths. It's just a parameter to the Attach method of your cDynamicDeviceProbe object 
- so your fantasy limits the possibilities. :-)
In the dynamite source you'll find a cDynamiteDeviceProbe which reacts on strings like 'dummydevice0' or 'dummydevice1'. 
It helped me while developing the SVDRP commands since I had only one DVB-T stick at my dev-vdr. You can activate it 
with a commandline argument.

There are some caveats if you would like to use other patches together with dynamite if they also extend cDevice. Every 
new method has to be investigated if it should return its own value or the one of the parentDevice or subDevice (if it's 
present). And every new virtual method has to be added to cDynamicDevice at the dynamite plugin. If I had 'the power' I 
would integrate the functionality of cDynamicDevice completly into cDevice and leave the controlling at the plugin - but 
I'm realistic enough to know, that that would need a lot of convincing for my part... :-)
As an example I added a reworked version of the lnb-sharing-patch to my repository[2]. Also I include some methods added 
by the patches yaVDR uses since this is my preferred distribution.

So, anything left to say? It took me a while to write all this stuff down so for now I don't know if I had forgotten 
something important or not. I'm looking forward for comments.

Of course I'm never responsible for broken or missed recordings (as no one is)! :-)

Thanks for reading!

Regards,
Lars.
--
P.S.: If you have a Sundtek stick and are interested in dynamite, please check out the sundtek-plugin[4]. It monitors 
devices via the libmedia/mediasrv and can even react on unplugging a device which is in use.
--
[1] http://projects.vdr-developer.org/projects/plg-dynamite/repository/revisions/master/entry/README
[2] git://projects.vdr-developer.org/vdr-plugin-dynamite.git
[3] http://projects.vdr-developer.org/projects/plg-pvrinput
[4] https://github.com/flensrocker/vdr-plugin-sundtek

[ANNOUNCE] dynamite plugin

Commit Message

Comments

Patch