It's your decision if you include it in your plugin, I think it's my responsibility when I combine several patches and apply dynamite on top of them.
If I don't include "SendDiseqcCmd" in the device-class of dynamite, rotorng will not work anyway.
In my opinion it's a "distributor" problem.
Yes, you're probably right. I think the patch in the rotorng patch should be for the pure VDR source without accounting for additional plugins etc.
Thanks
Thanks for all your work on this Lars.
Can you post the new patch when it's ready? I'll update the patch for vanilla VDR in the rotorng tar ball too.
Many Thanks
So are you saying it is now working with dynamite?
The broken error from rotorng is: -
Failed to send diseqc command!So, your message isn't related to this.
I haven't fixed this because I'm waiting for Lars to get back to me first.
Many Thanks
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...
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.
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 -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())Please test this and let me know how things go.
Thanks,
Morfsta
Is there a problem with the way YAVDR and its front-end starts now? I regularly see multiple instances of dbus-daemon in the process list: -
102 1313 1 0 13:21 ? 00:00:00 dbus-daemon --system --fork --activation=upstart
root 1354 1 0 13:21 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 1796 1 0 13:22 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 1968 1 0 13:22 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 1977 1 0 13:22 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 1986 1 0 13:22 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2340 1 0 13:23 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2355 1 0 13:23 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2373 1 0 13:23 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2393 1 0 13:23 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2406 1 0 13:24 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2421 1 0 13:24 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2490 1 0 13:24 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2561 1 0 13:24 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2578 1 0 13:25 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2589 1 0 13:25 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2602 1 0 13:25 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2613 1 0 13:25 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2624 1 0 13:26 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2635 1 0 13:26 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2646 1 0 13:26 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
root 2658 1 0 13:27 ? 00:00:00 //bin/dbus-daemon --fork --print-pid 4 --print-address 6 --session
and quite often the VDR frontend doesn't start properly, either showing the YAVDR blue logo or a black screen with mouse pointer and no frontend.
This happens frequently on a normal reboot, or wake from S3.
Is there anything I can do to debug this isseu further? It seems to happen with both xine front end and softhddevice. I am using a NVIDIA G210.
Thanks,
Morfsta
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
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
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.
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
Yes, something went wrong between vdr-1.7.22 and 1.7.27 on both yavdr 4.0 and when I installed 5.0.
When I get a moment I am going to try to see whether it works on vanilla VDR compiled up from source.
Alles anzeigenHi,
HVR4000(Lite): does it only have a DVB-S/S2-tuner? I know of some, that have an additional DVB-T-tuner (which adds a frontend1 to the adapter which can't be used simultaneous to frontend0 and vdr doesn't know that).
The error message from your first post says that vdr tries to use adapter1/frontend0 to send the diseqc command.
Does this match to your setup?
Lars.
It is just a single tuner, it is the HVR4000 Lite which doesn't include DVB-T just a single DVB-S/DVB-S2 tuner.
Here is DMESG: -
[ 8.742546] DVB: registering adapter 0 frontend 0 (Philips TDA10045H DVB-T)...
[ 8.749206] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1
[ 8.988869] cx88[1]: subsystem: 0070:9002, board: Hauppauge Nova-T DVB-T [card=18,autodetected], frontend(s): 1
[ 9.247288] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 9.632488] DVB: registering adapter 1 frontend 0 (Conexant CX24116/CX24118)...
[ 9.632818] cx8802_alloc_frontends() allocating 1 frontend(s)
[ 9.752176] DVB: registering adapter 2 frontend 0 (Conexant CX22702 DVB-T)...Here is dev tree: -
/dev/dvb$ ls -aR
.:
. .. adapter0 adapter1 adapter2
./adapter0:
. .. demux0 dvr0 frontend0 net0
./adapter1:
. .. demux0 dvr0 frontend0 net0
./adapter2:
. .. demux0 dvr0 frontend0 net0MrNike, you are using a different card to me and have the same problem?
Thanks & Regards
Do you maintain any source repository? Might you think it's possible to put in http://projects.vdr-developer.org/git/, or so?
Cheers
fnu
Yes, it is already on projects.vdr-developer.org and has been for awhile.
Regards
Alles anzeigen
Well ok, I missed that. But to be honest, the rotor stuff is not from our team nor our responsibility. Yes it's a shame that nobody does take care about that plugin and that it is still a patch needed for VDR.
From my point of view, this patch should be part of VDR like DiSEqC, SCR, DeviceBonding etc. not the function itself, I'm fine with a plugin. But we're neither responsible for VDR nor for vdr-plugin-rotorng.
If mini73 does fix it, I would guess it will become part for the next VDR version in 0.5, something like 1.7.31. I don't see it coming into 1.7.27 ...
Regards
fnu
Hi Fnu,
I am the maintainer of the plugin, I'm trying to take care of it by finding out what this issue is!
Yes, I wish rotor was included in VDR, but Klaus hasn't implemented it and I have asked him before. The Rotor plugin kept crashing, that is why I put the rotorng plugin together. I'm not a developer, I just tried to come up with a solution to the problem. The plugin is bundled with YAVDR and I'm trying to figure out why it doesn't work....
Alles anzeigenHi,
In the source I couldn't find anything that looks like an error.
The message in the syslog is a hint, that vdr tries to send it but the driver responds with "invalid argument", so the "patch-part" of rotorng seems to work.
Do you use "linux-media-dkms"? Which kind of dvb adapter do you use?
Lars
Hi,
No I am not using linux-media-dkms. Card is: -
[ 9.254979] cx88[0]: subsystem: 0070:6906, board: Hauppauge WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1
This adapter has always been fine until I updated from yavdr 4.0 to 5.0.
Thanks mini73.
Let me know if I can help in any way.
Hmmm, that's not such a great response. 
I checked and it seems the rotor patch is still included in the source tree and cDvbDevice SendDiseqcCmd is still in dvbdevice.c.
Thanks. Let me know if there's anything at all I can help with, including testing.
Regards
Hi,
I am the maintainer of the rotorng source.
Firstly, congratulations on yavdr 0.5.0. It is the fastest, most pain free installation of VDR/YAVDR that I have ever completed - only 1-2 hours to totally rebuild my HTPC. The remote and sound worked out of the box on my system! Amazing!
However, as part of the upgrade from vdr-1.7.22 to 1.7.27 (both within my previous yavdr 0.4 installation using "apt-get upgrade" and from yavdr 0.4 - 0.5) the rotorng plugin has broken. This is shown in the syslog when I try to send a disecq command: -
vdr: [8287] ERROR: frontend 1/0: Invalid argument
Just to recap, the patch within YAVDR VDR source (opt-44_rotor.patch) adds another method to cDvbTuner: -
+bool cDvbTuner::SendDiseqcCmd(dvb_diseqc_master_cmd cmd)
+{
+ cMutexLock MutexLock(&mutex);
+ if ((frontendType!=SYS_DVBS2 && frontendType!=SYS_DVBS) 
SendDiseqc)
+ return false;
+ diseqc_cmd=cmd;
+ SendDiseqc=true;
+ newSet.Broadcast();
+ return true;
+}
and modifies cDvbTuner::GetFrontendStatus with: -
cMutexLock MutexLock(&mutex);
+ if (SendDiseqc) {
+ CHECK(ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, &diseqc_cmd));
+ SendDiseqc=false;
+ }
Has anything changed in YAVDR, or perhaps the driver that means this no longer works the way that it used to? I've spoken to Klaus on the VDR mailing list and he can't think of anything in core VDR.
Previously we found that the dynamite plugin broke rotorng, but dynamite is still disabled in my setup.
Please let me know if there is anything I can do to debug this problem.
Regards
