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
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
