[vdr] Rotor / Rotor-NG not working with latest VDR

Lars Hanisch dvb at flensrocker.de
Tue Jan 3 17:06:29 CET 2012


Hi,

Am 03.01.2012 11:43, schrieb Morfsta:
> On Sun, Dec 25, 2011 at 12:32 PM, ilia mane<ilmima64 at gmail.com>  wrote:
>> Thank you Lars Hanisch it work for me.I just disable the dynamite plugin in
>> /etc/vdr/plugins/order.conf and the rotorng plugin work now.
>
> Just returned from the Christmas period, merry Christmas all!
>
> Then it looks like dynamite is the problem. Rotorng has a setup option
> for the satellite adapter that is connected to the rotor and normally
> it is set to 1,2,3 etc depending on the allocated adapter # at boot
> up. I guess this might now change with this virtual proxy for the
> adapter that is setup by dynamite?
>
> How is this handled, for example by femon or other plugins that need
> to communicate with the required physical adapter #?

  A quick grep in the femon sources shows me, that femon opens the frontend on its own. It will use the device's 
"CardIndex()" as adapter number and will always open frontend0 (which will break even without dynamite on 
multi-frontend-devices). For now dynamite will not guarantee that adpater #0 will have cardindex #0. If you want to 
correlate the shown info to your devices, you'll have to look in the dynamite settings -> list all devices (or use the 
SVDRP command "plug dynamite lstd").

  It is possible to assign adapters to specific cardindices with the udev environment variable "dynamite_cardindex". But 
one should use this on all adapters since the logic behind this is not so smart to first attach all devices with a set 
cardindex and then all others.

  I think it might be a good idea if dynamite will use the adapter number as a hint for the cardindex.


  I can imagine these things, that will lead to problems with dynamite:
- new virtual functions in cDevice or cDvbDevice: they have to be patched into dynamite's cDynamicDevice so it can 
forward calls to its subdevice
- new non-virtual member functions in cDevice/cDvbDevice: for every method it has to be evaluated if the "parent's" or 
"subdevice's" value has to be return (e.g. CardIndex, DeviceNumber, PatPmtParser, CamSlot etc.). It depends from where 
and in which context these functions are called (has the caller a pointer to a subdevice like a call from within 
cDvbDevice - has it a pointer from the cDevice::device array which will point to the parent device etc.).
- dynamic_cast<cDeviceSubclass> (like it is used with the new device bonding feature): plugins won't get the "real" 
device like cDvbDevice or similar. It will always be a cDynamicDevice.

  rotorng adds one new virtual function to cDevice: SendDiseqcCmd
  In yavdr this is included in the dynamite plugin (as "nm -d /usr/lib/vdr/plugins/libvdr-dynamite.so.1.7.22" confirms).
  When I look at the cDevice-functions rotorng is using I don't see anything which will lead to problems. Maybe it's 
just a cardindex mismatch?

  There are two ways to test this (after reactivating dynamite with an * in /etc/vdr/plugins/order.conf, which will 
ensure that dynamite loads as the last plugin):

1. The "fast" way: Detach all devices from vdr with "svdrpsend plug dynamite dtad"
    Reattach them in the "right" order with "svdrpsend plug dynamite attd /dev/dvb/adapter0/frontend0" etc.

2. The other way: Add a udev rule to your system that will assign every frontend a cardindex, it may look like:

  ACTION=="add", SUBSYSTEM=="dvb", ENV{DVB_DEVICE_TYPE}=="frontend", ENV{dynamite_cardindex}="%E{DVB_ADAPTER_NUM}"

  Reload the modules and restart vdr. This assumes you have no card with multiple frontends.


Thanks,
Lars.

>
> Thanks,
>
> Morfsta
>
> _______________________________________________
> vdr mailing list
> vdr at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>



More information about the vdr mailing list