Difference between revisions of "Dynamite-plugin"
(Created page with "==Description== '''Author:''' Lars Hanisch This plugin allows to add/remove receiving devices from VDRs device list at runtime. This is interesting for USB devices that are onl...")
|Line 64:||Line 64:|
# [http://projects.vdr-developer.org/projects/show/plg-dynamite Plugins Homepage]
Revision as of 19:00, 2 December 2013
Author: Lars Hanisch
This plugin allows to add/remove receiving devices from VDRs device list at runtime.
This is interesting for USB devices that are only temporarily plugged to VDR to solve timer conflicts. Or even for devices that have a long init phase and thus delay vdr startup. With internal PCI DVB cards could be already in use, while slower cards dalayed "wake up" and start their work.
Furthermore deadlocked drivers or hardware can be restarte without disturbing current recordings.
How does it work?
The dynamite plugin contains a class derived from cDevice (cDynamicDevice) similar to the dummydevice outputs as blunt stupid receiver - it can purely receive nothing. Through the patch cDevice itself is extended to include two properties, parentDevice and subDevice. These are now used by cDynamicDevice to "learn" something. If a new DVB device is plugged to system (eg via USB), dynamite responds on appropriate udev event as soon as the frontend is registered. After that the list of cDvbDeviceProbe objects is scoured, until one feels responsible and and creates a cDvbDevice. This object is then mounted as "subDevice" in an existing, free cDynamicDevice. And from that time this cDynamicDevice can receive everything that his subDevice can.
To do this, cDynamicDevice needs to overload all virtual methods of cDevice and pass to its present subDevice - or return the default value of cDevice. In addition, it is also necessary to adapt some non-virtual methods, depending on what they do, call the appropriate method of the subDevice or the one of the ParentDevice.
If dynamite is combined with other patches or plugins, there may be adaptions necessary.
Working with other Plugins
cDynamicDeviceProbe was introduced to allow other plugins using this device hotplug. (see patched device.h)
If dynamite is instructed by SVDRP command to attach a device "/dev/video0" (svdrpsend plug dynamite attachdevice /dev/video0), the list is scanned until a cDevice derived object is given back. In this example, pvrinput will react and instantiate an object of class cPvrDevice. This is attached by dynamite and from this time analogue TV can be used (if supported by pvrinput).
Similarly this object can be destroyed by "svdrpsend plug dynamite detachdevice /dev/video0".
dynamite opens the possibility to react on some udev events. For example, pvrinput calls dynamites service interface "dynamite-AddUdevMonitor-v0.1" and passes paramters "video4linux /dev/video". After that, dynamite creates an udev monitor for subsystem "video4linux". As soon as an "add" event with device node "/dev/video0" is noticed, the complete Devnode string is passed to cDynamicDeviceProbe. If supported by pvrinput, it now creates an cPvrDevice object.
As vdr is already delivered with class cDvbDevice, by default an udev monitor for subsystem "dvb" is running.
Sequence of loading Plugins
dynamite creates cDynamicDevice objects to entirely fill VDRs internal device array. Therefore plugins creating devices that should not be handled by dynamite, have to be loaded before dynamite starts. This includes output plugins, but also streamdev-client, iptv and so on.
this is not needed for plugins, beeing "dynamite-aware".
# go to folder with vdr sources. From there; cd PLUGINS/src # first time getting sources: git clone git://projects.vdr-developer.org/vdr-plugin-dynamite.git dynamite # otherwise cd dynamite ; git pull ; cd .. # after that.. cd ../.. # if patch is not yet applied.. patch -n1 < PLUGINS/src/dynamite/vdr-<VERSION>-dynamite.patch # und übersetzen... make plugins