Hi,
Am 03.01.2012 11:43, schrieb Morfsta:
On Sun, Dec 25, 2011 at 12:32 PM, ilia mane<ilmima64@xxxxxxxxx> 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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
