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