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