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.
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.
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
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_richter@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
Hi,
Am 25.07.2011 21:18, schrieb Udo Richter:
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.
Since I'm working on the unicable patch and try to wrap my brain around the whole diseqc stuff, I'm not sure if the implementation is designed for more than one code sequence per line. But it's a guess as well.
Lars.
Cheers,
Udo
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 01.09.2011 00:30, L. Hanisch wrote:
Hi,
Am 25.07.2011 21:18, schrieb Udo Richter:
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 [..]
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.
Since I'm working on the unicable patch and try to wrap my brain around the whole diseqc stuff, I'm not sure if the implementation is designed for more than one code sequence per line. But it's a guess as well.
It *is* supposed to work with any number of code sequences per entry.
BTW: I'm planning on adopting the unicable patch in the next developer version. Just received the necessary hardware for testing this week.
Klaus
It *is* supposed to work with any number of code sequences per entry.
BTW: I'm planning on adopting the unicable patch in the next developer
version.
Just received the necessary hardware for testing this week.
Klaus
Dear Klaus,
thanks for your effort to enhance the functionality of VDR to common needs and feel free to come back to me in case somebody needs to test or verify things for EN50494, SCR, Unicable (TM) implementation.
Since known patch only seems to work until version 1.7.18 w/o re-work, Lars tries to get it the stuff work for yaVDR w/ 1.7.20 ... and well yes, he learns a lot to understand the function and me a little bit, too.
Cheers Frank
-
fnu -
Hawes, Mark -
Klaus Schmidinger -
L. Hanisch -
Udo Richter