Re: [vdr] Diseqc problems with VDR1.7.19
I've done some further investigation and as far as I can tell the problem appears to be with the value returned by cDiseqc::Codes in diseqc.c. The return value changed from 'uchar' to 'const uchar' between 1.7.18 and 1.7.19 and the returned value now always points to the last diseqc code in the string. The following trace from 1.7.19 shows the problem: Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250 [E1 31 6B 01] W15 T Entered cDiseqc::Codes pointing at : E0 10 38 F4] In cDiseqc::Codes - returning a pointer 137345561 to : W500 [E0 31 Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 Entered cDiseqc::Codes pointing at : E0 31 6B 01] In cDiseqc::Codes - returning a pointer 137345580 to : W250 [E1 31 Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 Entered cDiseqc::Codes pointing at : E1 31 6B 01] In cDiseqc::Codes - returning a pointer 137345599 to : W15 T Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 The identical trace from 1.7.18 which works correctly looks like this: Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250 [E1 31 6B 01] W15 T Entered cDiseqc::Codes pointing at : E0 10 38 F4] In cDiseqc::Codes - returning a pointer 137333177 to : W500 [E0 31 Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4 Sending Diseqc command: E0 10 38 F4 Entered cDiseqc::Codes pointing at : E0 31 6B 01] In cDiseqc::Codes - returning a pointer 137333196 to : W250 [E1 31 Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01 Sending Diseqc command: E0 31 6B 01 Entered cDiseqc::Codes pointing at : E1 31 6B 01] In cDiseqc::Codes - returning a pointer 137333215 to : W15 T Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01 Sending Diseqc command: E1 31 6B 01 I have tried to revert cDiseqc::Codes in 1.7.19 to the 1.7.18 version but the extent of the changes introduced to 1.7.19 in this area eventually defeated my limited C++ skills. In doing so I have learnt and read a lot and it appears that there are some pitfalls in returning 'const' values. I suspect that this is the problem here but can't be sure. If someone could have a look at this and suggest how to fix it, it would be much appreciated. Thanks, Mark. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Am 25.07.2011 13:12, schrieb Hawes, Mark:
I’ve done some further investigation and as far as I can tell the
problem appears to be with the value returned by cDiseqc::Codes in
diseqc.c.
The following trace from 1.7.19 shows the problem:
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
The identical trace from 1.7.18 which works correctly looks like this:
Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01
Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s) const:
int n = strtol(t, p, 16);
if (!errno p != t 0 = n n = 255) {
if (parsing) {
codes[NumCodes++] = uchar(n);
numCodes = NumCodes;
My guess is that it must be if (!parsing) instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Thanks Udo, that seems to have done the trick.
I guess Klaus will pick this up as a matter of course ...
Regards,
Mark.
-Original Message-
From: Udo Richter [mailto:udo_rich...@gmx.de]
Sent: Tuesday, 26 July 2011 5:19 AM
To: VDR Mailing List
Subject: Re: [vdr] Diseqc problems with VDR1.7.19
Am 25.07.2011 13:12, schrieb Hawes, Mark:
I've done some further investigation and as far as I can tell the
problem appears to be with the value returned by cDiseqc::Codes in
diseqc.c.
The following trace from 1.7.19 shows the problem:
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137345509 to : E1 31 6B 01
The identical trace from 1.7.18 which works correctly looks like this:
Received from diseqc-Codes(n) a pointer 137333125 to : E0 10 38 F4
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E0 31 6B 01
[..]
Received from diseqc-Codes(n) a pointer 137333125 to : E1 31 6B 01
Without further trying, my wild guess is that the bug is in the
following code fragment of const char *cDiseqc::Codes(const char *s)
const:
int n = strtol(t, p, 16);
if (!errno p != t 0 = n n = 255) {
if (parsing) {
codes[NumCodes++] = uchar(n);
numCodes = NumCodes;
My guess is that it must be if (!parsing) instead. The switch seems to
be true for syntax checking from cDiseqc::Parse() (the conf file
parser), and false otherwise. The way it is, the values in codes[] only
change when called from the file parser, and then stay at the last code
sequence that has been parsed forever.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Diseqc problems with VDR1.7.19
Hi, Since upgrading to VDR 1.7.19 I have experienced problems with Diseqc. My diseqc configuration uses command strings which contain 3 code sets: a diseqc switch command, a diseqc go to command, and a repeat goto command. Since upgrading to VDR 1.7.19 it appears that the only code set sent is the last one, but it's sent three times. To demonstrate this I have put some trace in cDvbTuner::SetFrontend within dvbdevice.c which traces the complete diseqc string, the diseqc action, and for diseqc codes - the actual diseqc code sent. It produces the following output: Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250 [E0 31 6B 04] W15 T Diseqc action = 1 Diseqc action = 3 Diseqc action = 7 Sending Diseqc command: E0 31 6B 04 Wrong, should be E0 10 38 F4 Diseqc action = 7 Sending Diseqc command: E0 31 6B 04 Wrong, should be E0 31 6B 04 Diseqc action = 7 Sending Diseqc command: E0 31 6B 04 Diseqc action = 2 The same trace in vdr 1.7.18 shows the correct codes being sent in the correct sequence. I note that some work was done in this area for 1.7.19 but my C++ skills are a little weak to diagnose the problem any further. Can anybody throw some more light on what's going on? Thanks, Mark. Mark Hawes Senior Project Manager Fujitsu Australia Limited 825 Bourke Street, Docklands VIC 3008, Australia T +61 3 9924 3240 M +61 416 140 218 F +61 3 9924 3001 mark.ha...@au.fujitsu.com mailto:mark.ha...@au.fujitsu.com au.fujitsu.com http://au.fujitsu.com image001.gif___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Diseqc problems with VDR1.7.19
Just looked at the trace I sent in my initial post and realised that I had selected a Diseqc command that I had modified while trying to diagnose the situation so my annotations were a bit misleading. The following should be less confusing: Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250 [E1 31 6B 04] W15 T Diseqc action = 1 Diseqc action = 3 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Wrong, should be E0 10 38 F4 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Wrong, should be E0 31 6B 04 Diseqc action = 7 Sending Diseqc command: E1 31 6B 04 Diseqc action = 2 Again, the final Diseqc command has been sent three times, not the three commands in the sequence they appear in the command list. Apologies for the confusion. Mark. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
