[yavdr 0.5] RotorNG broken

mini73 · 20. Oktober 2012

Zitat von morfsta

When I get a moment I am going to try to see whether it works on vanilla VDR compiled up from source.

That's a good point to start with.

Lars.

morfsta · 22. Oktober 2012

OK, I have found the problem(s) in both the patch and the plugin and I now have a working rotorng implementation again in yavdr-0.5.0.

I need to look into a few things first but I will send through a new patch shortly and release a new version of the plugin...

Thanks

mini73 · 22. Oktober 2012

Hi,

Hey, that's good news!

Lars.

MrNike · 24. Oktober 2012

That is great news. Will be looking forward to see what the problem was.

Greetings,
MrNike

morfsta · 24. Oktober 2012

I have been a bit busy with work this week, but I will release something soon.

I want to see whether it is possible to remove the requirement for the VDR patch completely.

mini73 · 24. Oktober 2012

No need to hurry, we all have another (some say "real") life...

"no patch" would be cool, I'm curious...

Lars.

jan23 · 24. Oktober 2012

Zitat von morfsta

I have been a bit busy with work this week, but I will release something soon.

I want to see whether it is possible to remove the requirement for the VDR patch completely.

Hi,

this is a great news, thanks !

I don't know what the problem is with yavdr but I can confirm that rotorng and rotor-0.1.5 is working properly with the latest versions of standard vdr (and TT S2-6400), including version 1.7.31.

Attached both plugins (rotorng is practically the same of yavdr, I think ?(. Thanks to yavdr-team for his work!)

ciao

Jan

morfsta · 25. Oktober 2012

Thanks for confirming that it worked with vanilla VDR.

The problem with yavdr was the VDR patch had been updated to change how it identified the delivery system (DVB-S or DVB-S2) and for some reason this patch is a little overcomplicated and doesn't work. There are functions already in VDR core to do this and it didn't need the additional function that had been included in the patch. This was the cause of the "Invalid Argument" type errors and is now fixed.

There was also a problem with the cStatusMonitor::ChannelSwitch method, it has changed in core VDR to add another parameter (bool LiveView), I think in VDR 1.7.26 which wasn't updated in rotorng, so when changing channel the rotor also didn't work.

Now, rather than implementing new code in VDR for SendDiseqcCmd, I believe we might be able to use the "ExecuteDiseqc" function that is already in VDR, I think that was implemented for the LNB sharing code. If so, there should be no further requirement for a patch.

I will look at this maybe today and provide an update later.

Cheers,

Morfsta

mini73 · 25. Oktober 2012

Hi,

Yes, there are several plugins affected by the ChannelSwitch changes.
If it's possible to use ExecuteDiseqc that would be great! Every obsoleted patch is a good patch.

It may also appear complicated because I tried to get it work with dynamite. When you finished your work I will have a look at it if it's then easier.

Lars.

morfsta · 25. Oktober 2012

It would be good also to get it working with dynamite as currently I must disable this.

I understand that dynamite creates a "proxy" type virtual device between the physical device and userspace? Currently rotorng uses the physical card instance setup in a setup option to send the command to, how does this change with dynamite and how do we know which card to use etc? We would also need to make sure that dynamite passes on the ioctl to the real device.

Thanks

mini73 · 25. Oktober 2012

Yes, you're right. The "dynamite"-devices pass through all calls to the virtual functions of cDevice.
It won't work, if plugins needs some "special" device as:

Code

cDvbDevice* dvbdevice = reinterpret_cast<cDvbDevice*>(cDevice::GetDevice(i));

since the devices at the array in cDevice aren't cDvbDevices anymore. In such cases you have to test the "subdevice". I add some new functions to cDevice for this purpose, see https://github.com/flensrocker…-dynamite-subdevice.patch, esp. line 362 and following (the changes at device.h).
But it's too theoretical, just get your plugin working with vanilla vdr and then we can look at the parts which communicates with the devices. Often there isn't much to do and it's easier to explain with a real example.

Lars.

morfsta · 25. Oktober 2012

OK, there is a new version of the rotorng plugin at: -

http://projects.vdr-developer.…d/1087/rotorng-0.3.tar.gz

Which includes a patch against vanilla vdr-1.7.27 in it.

Here is a patch against the YAVDR VDR source tree to fix the problem: -

Diff

diff -u vdr-1.7.27/dvbdevice.c vdr-1.7.27-updated/dvbdevice.c
--- vdr-1.7.27/dvbdevice.c      2012-10-21 21:12:46.000000000 +0100
+++ vdr-1.7.27-updated/dvbdevice.c      2012-10-21 20:45:23.138985014 +0100
@@ -680,17 +680,6 @@
   return Frontend[0].u.data;
 }


-bool cDvbTuner::SendDiseqcCmd(dvb_diseqc_master_cmd cmd)
-{
-  cMutexLock MutexLock(&mutex);
-  int frontendType = GetCurrentDeliverySystem();
-  if ((frontendType != SYS_DVBS && frontendType != SYS_DVBS2) || SendDiseqc)
-    return false;
-  diseqc_cmd=cmd;
-  SendDiseqc=true;
-  newSet.Broadcast();
-  return true;
-}




 static unsigned int FrequencyToHz(unsigned int f)
@@ -755,6 +744,20 @@
   return ds;
 }


+bool cDvbTuner::SendDiseqcCmd(dvb_diseqc_master_cmd cmd)
+{
+  cMutexLock MutexLock(&mutex);
+  cDvbTransponderParameters dtp(channel.Parameters());
+  int frontendType = GetRequiredDeliverySystem(&channel, &dtp);
+  if ((frontendType != SYS_DVBS && frontendType != SYS_DVBS2) || SendDiseqc)
+    return false;
+
+  diseqc_cmd=cmd;
+  SendDiseqc=true;
+  newSet.Broadcast();
+  return true;
+}
+
 bool cDvbTuner::SetFrontend(void)
 {
   if (!OpenFrontend())

Alles anzeigen

Please test this and let me know how things go.

Thanks,

Morfsta

fnu · 25. Oktober 2012

Zitat von morfsta

Code

+ cDvbTransponderParameters dtp(channel.Parameters());

So, just one additional line of code, is that right?

Regards
fnu

morfsta · 25. Oktober 2012

Two lines and a move of the function to below another.

BTW if GetCurrentDeliverySystem() is not used by anything else then this can also be removed.

fnu · 25. Oktober 2012

Zitat von morfsta

Yes and a move of the function.

Ok, let's test if this change does harm any of the other functions, DiSEqC, Device Bonding, SCR. If not it might be small enough to ask for general usage in VDR ...

If it does compile w/o issues in our VDR package, I think about to put it into VDR 1.7.27 of 0.3/0.4 stable-vdr, also the new plugin version.

Regards
fnu

morfsta · 25. Oktober 2012

OK, I have asked Klaus on the mailing list if we can make some of diseqc functions public in the VDR core so we can use them in the plugin...

mini73 · 25. Oktober 2012

Hi,

The patch won't harm the other functions since it's introduced by the rotor-patch and isn't used by anyone else.

I'll have a look at this, too, maybe that other function (GetCurrentDeliverySystem) was written by me.
Thanks for the patch.

So you didn't get ExecuteDiseqc to work without a vdr-patch?

Lars.

mini73 · 25. Oktober 2012

It's a good idea to get such functionality publically available for plugins.
I hope Klaus will adopt it.

Lars.

MrNike · 26. Oktober 2012

Zitat von morfsta

OK, there is a new version of the rotorng plugin at: -

Please test this and let me know how things go.

Thanks,

Morfsta

Alles anzeigen

Just updated via the yavdr ppa and it seems to be working fine Need to do some more testing later, but at first sight it looks very good.
Thanks for your work !

Greetings,
MrNike

mini73 · 26. Oktober 2012

Hi MrNike,

Interesting - which package did you take? Ah, I see, you're using unstable-vdr, than it's ok.
If it's working I will backport the patch to vdr 1.7.27 for testing and stable. Will do this weekend.

What about dynamite? Have you disabled it? Can you test with dynamite enabled, please?

Lars.

[yavdr 0.5] RotorNG broken

Jetzt mitmachen!

Teilen