Project

General

Profile

News

0.0.6a: now with OSD (1 comment)

Added by lhanisch over 13 years ago

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

0.0.6: use more udev magic (3 comments)

Added by lhanisch over 13 years ago

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.

0.0.5i: first alpha of "idle devices"

Added by lhanisch almost 14 years ago

What it should do
set device to idle
=> device close all its handles
=> device is ignored by epg-scan
=> any receiver/timer etc. will reactivate the device

Issues
  • 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)

0.0.5h: call an external program if GetTS-watchdog triggers

Added by lhanisch almost 14 years ago

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.

What is missing:
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...

Setting the watchdog-timeout with udev (1 comment)

Added by lhanisch almost 14 years ago

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.

What I learned about the EITScanner (1 comment)

Added by lhanisch almost 14 years ago

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

    (1-6/6)

    Also available in: Atom