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@xxxxxx] Sent: Tuesday, 26 July 2011 5:19 AM To: VDR Mailing List Subject: Re: 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@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
