Difference between revisions of "Dynamite-plugin"

From VDR Wiki
Jump to: navigation, search
(Links)
 
(2 intermediate revisions by one user not shown)
Line 4: Line 4:
 
This plugin allows to add/remove receiving devices from VDRs device list at runtime.
 
This plugin allows to add/remove receiving devices from VDRs device list at runtime.
  
 +
===Status===
 +
Last Update 10/2013
 +
 +
===Detailed Description===
 
This is interesting for USB devices that are only temporarily plugged to VDR to solve timer conflicts.
 
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.
 
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.
Line 43: Line 47:
  
 
==Developer Version==
 
==Developer Version==
[https://github.com/flensrocker/vdr-plugin-dynamite oder bei github.com]
+
[https://github.com/flensrocker/vdr-plugin-dynamite github.com]
 
ie.
 
ie.
 
<pre>
 
<pre>
Line 61: Line 65:
  
 
==Current Version==
 
==Current Version==
[http://projects.vdr-developer.org/attachments/download/819/vdr-dynamite-0.0.8i.tgz 0.0.8i]
+
[http://projects.vdr-developer.org/attachments/download/1546/vdr-dynamite-0.1.5.tgz 0.1.5]
  
 
==Links==
 
==Links==

Latest revision as of 21:40, 2 December 2013

Description

Author: Lars Hanisch

This plugin allows to add/remove receiving devices from VDRs device list at runtime.

Status

Last Update 10/2013

Detailed Description

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.

Info
Info

I try to keep the README as up-to-date as possible in the plugin source code, so you should read that in any case, before giving dynamite a "blind" try. There are explainations of all SVDRP commands and vdr-internal service interface for example.


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".


Software Requirements

  • libudev-dev

Developer Version

github.com ie.

# 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

Current Version

0.1.5

Links

  1. Plugins Homepage