[vdr] Diseqc problems with VDR1.7.19

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Thu Sep 1 18:09:50 CEST 2011

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.


More information about the vdr mailing list