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_rich...@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




_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Reply via email to