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