On 12/20/11 09:49, Morfsta wrote:

Hi,

I have just upgraded my VDR system to yavdr 0.4.0 which uses VDR 1.7.21 and I notice that the Rotor plugin and my own Rotor-ng plugin no longer drive the rotor using any of the functions in the menu.

Is anyone else seeing this too?

I think that this could be because of recent changes to disecq handling code within VDR as part of the Unicable update. Klaus could you point me in the direction of what might have changed such that these plugins no longer work and I will do my best to implement a fix.

Thanks very much for your help,

Regards,

Morfsta

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Hi Morfsta,

I also had to implement changes into Seppo patch for gotoxx - so maybe you could take a look into the latest version of gotoxx patch for 1.7.22, it is working without problems, hope it helps.

You could find the patch at http://www.linuxtv.org/pipermail/vdr/2011-December/025511.html

Best Regards,

Ales

On Tue, Dec 20, 2011 at 9:23 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:

On 20.12.2011 09:49, Morfsta wrote:

I don't see what could have changed in version 1.7.21 that might have an impact on this. "Satellite Channel Routing" (SCR) and "Device Bonding" (unicable) were implemented in later versions.

I think the yavdr VDR distribution has the Unicable patch applied to 1.7.21, there is an option "log LNB usage" in the LNB menu and there is a # Unicable set of entries in the disecq.conf file.

The rotor and rotorng plugin use: -

if (ActuatorDevice->SendDiseqcCmd(switch_cmds[KNr]))

to send the disecq sequence to move the rotor where KNr is the device number with the rotor atached.

Has this means to send the disecqc command now changed as part of unicable support both in core VDR 1.7.21 and as part of the patch?

Kind Regards,

Morfsta

On 12/20/11 21:51, Morfsta wrote:

On Tue, Dec 20, 2011 at 9:20 AM, Ales Jurik ajurik@quick.cz wrote:

...

I also had to implement changes into Seppo patch for gotoxx - so maybe you could take a look into the latest version of gotoxx patch for 1.7.22, it is working without problems, hope it helps.

You could find the patch at http://www.linuxtv.org/pipermail/vdr/2011-December/025511.html

I don't know the previous patch, what did you have to change?

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

The previous version you could find at http://www.linuxtv.org/pipermail/vdr/2011-January/024430.html. I'm not personally sure whether it was working with 1.7.21, but I've heard that it was. I've personally used it with 1.7.16 and 1.7.18.

Regards,

Ales

Please install the latest updates with: $ sudo apt-get update $ sudo apt-get dist-upgrade

There was an error in the vdr-plugin dynamite's Makefile.

Hi there,

Thanks for your help, but the rotor / rotorng plugins still don't work after the update.

Any other ideas?

Kind Regards,

Morfsta

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.

On Sat, Dec 24, 2011 at 10:59 AM, Lars Hanisch dvb@flensrocker.de wrote:

Hi,

Am 23.12.2011 20:07, schrieb Morfsta:

Please install the latest updates with:

...

...

$ sudo apt-get update $ sudo apt-get dist-upgrade

There was an error in the vdr-plugin dynamite's Makefile.

Hi there,

Thanks for your help, but the rotor / rotorng plugins still don't work after the update.

Any other ideas?

I don't see a dynamite related problem after a quick look over the source of the plugins in the yaVDR PPA. The vdr-patch adds a new method to cDevice and dynamite is aware of it.

Please take a look at 'nm -D /usr/lib/vdr/plugins/libvdr-**dynamite.so.1.7.21' if there's a symbol cDynamicDevice::SendDiseqcCmd.

If you'r familiar with build debs you can try to rebuild vdr with some logmessages in the SendDiseqcCmd methods of dvbdevice.c to see if there are really sent. I have only DVB-C and can't really test it.

Some words to dynamite, a core functionallity of yaVDR: It creates devices "between" vdr and the "real" devices like a proxy passing all virtual methods to its subdevice. This makes it possible to start vdr with a lot of dummy devices (not to mix with the plugin) and attach the dvbdevices when they are created, e.g. if they get plugged in via USB. Also dynamite is able to set unused devices to an idle state, which means that it closes all its filehandles including the frontend. Please look in /etc/vdr/plugins/plugin.**dynamite.conf if an idle-timeout is specified.

dynamite is running in the yavdr team for months and hasn't shown many problems. But I don't think that anyone of us has tested it with rotor(ng).

And take a look at the dynamite repository. There are patches for other plugins which need to be patched.

I hope we can get rotor back to work again!

If you have dvb hardware, which initialises fast on boot (like PCI/PCIe devices) you can try to disable dynamite in the /etc/vdr/plugins/order.conf, just insert a minus before it. But be aware to insert a * if you want to use it again, since this is needed to asure that dynamite is the last plugin that gets loaded.

Regards, Lars.

...

Kind Regards,

Morfsta

______________________________**_________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdrhttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

______________________________**_________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdrhttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Hi,

Am 03.01.2012 11:43, schrieb Morfsta:

On Sun, Dec 25, 2011 at 12:32 PM, ilia maneilmima64@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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr