-
Notifications
You must be signed in to change notification settings - Fork 1
News (archive)
This is a copy of https://projects.vdr-developer.org/projects/plg-dynamite/news, created because https://projects.vdr-developer.org might come to an end
Added by [lhanisch] 2011-03-25
Finally I managed to add some items to the OSD for controlling dynamite. With your remote control you can now:
- list the attached devices
- scan for new DVB devices (search pattern /dev/dvb/adapter*/frontend*)
- detach a device
- lock/unlock a device
- switch a device to idle
Added by [lhanisch] 2011-03-24
There are two new udev device properties which can be used by dynamite to control which devices should be attached and which not.
To keep /dev/dvb/adapter2/frontend* from being attach to every vdr instance:
ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_ADAPTER_NUM}=="2", ENV{dynamite_attach}="no"
This would attach /dev/dvb/adapter2/frontend* to the vdr with the instance id "1" and all other frontends to the vdr instance "0":
ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_ADAPTER_NUM}=="2", ENV{dynamite_instanceid}="1" ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_ADAPTER_NUM}!="2", ENV{dynamite_instanceid}="0"
To bridge gaps in the numbering of the dvb adapters dynamite uses udev to scan for dvb frontends at startup. This ensures that every frontend will be found even if they are /dev/dvb/adapter1, /dev/dvb/adapter5 and /dev/dvb/adapter7.
Added by [lhanisch] 2011-02-17
set device to idle => device close all its handles => device is ignored by epg-scan => any receiver/timer etc. will reactivate the device
- dvbdevice doesn't close its ca, only frontend and demux are closed till now
- no automatism for setting a device into idle mode
(patch of vdr is modified)
Added by [lhanisch] 2011-02-17
add to your setup.conf:
dynamite.GetTSTimeoutHandler = /path/to/program
This program will be called with the devpath of the detached device as an argument.
You can replace this argument with the value of the udev-device-property "dynamite_timeout_handler_arg":
ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", ENV{dynamite_timeout}="5", ENV{dynamite_timeout_handler_arg}="%k"
In this example "%k" expand to "dvb0.frontend0" for the first dvb-device.
dynamite doesn't enumerate the udev-device-properties of the device at startup, so "dynamite_timeout_handler_arg" onyl works for devices attached by the udev-monitor.
it's on the todo list...
Added by [lhanisch] 2011-02-10
In a udev rule you have the possibility to set properties on the device which gets currently added.
This udev rule
ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", ENV{dynamite_timeout}="10"
adds the property "dynamite_timeout" with a value of "10" to every frontend.
The dynamite udev-monitor now parse this property and sets automatically the timeout for this device. If you only have one specific device for which you want to set a timeout you only have to identify this device in your udev rule, set the timeout and you're done.
But for now this only works for devices which gets attached with the udev-monitor. It is not working for devices which are present when vdr/dynamite starts.
I had to modify the vdr-patch a bit but there shouldn't be any ABI changes.
I add a new command for cDynamicDeviceProbe called "ddpcService". With this command you can queue calls to the dynamite-Service-interface. Since the udev-monitor queues the attach-command for a new dvb-device it can't set the timeout immediately after queueing. It has to be queued, too. Hence the new command which makes this more flexible.
Added by [lhanisch] 2011-02-02
For all non-virtual methods of cDevice which are called by plugins or cDvbDevice I have to decide, if it has to be modified. Should it return the value of the sub-device or the parent-device? Or just its value regardless of sub or parent?
cDvbDevice uses "Receiving" and "IsPrimaryDevice" to decide whether it provides the given channel or not. But only the parent device can return the right values so these methods have to be modified by the vdr-patch.
Hopefully the EITScanner won't interfere with live-tv if you have more than one device...