Re: [vdr] Diseqc problems with VDR1.7.19

[fnu]

> 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

Dear Klaus,

thanks for your effort to enhance the functionality of VDR to common needs
and feel free to come back to me in case somebody needs to test or verify
things for EN50494, SCR, Unicable (TM) implementation.

Since known patch only seems to work until version 1.7.18 w/o re-work, Lars
tries to get it the stuff work for yaVDR w/ 1.7.20 ... and well yes, he
learns a lot to understand the function and me a little bit, too.

Cheers
Frank


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

Re: [vdr] Diseqc problems with VDR1.7.19

[Klaus Schmidinger]

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

Re: [vdr] Diseqc problems with VDR1.7.19

[L. Hanisch]

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

Re: [vdr] Diseqc problems with VDR1.7.19

[Hawes, Mark]

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

Re: [vdr] Diseqc problems with VDR1.7.19

[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.


Cheers,

Udo

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

Re: [vdr] Diseqc problems with VDR1.7.19

[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 return value changed from 'uchar' to 'const uchar' between 1.7.18
and 1.7.19 and the returned value now always points to the last diseqc
code in the string.

The following trace from 1.7.19 shows the problem:

 

Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250
[E1 31 6B 01] W15 T

  Entered cDiseqc::Codes pointing at : E0 10 38 F4]

  In cDiseqc::Codes - returning a pointer 137345561 to :  W500 [E0 31

Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01

Sending Diseqc command: E1 31 6B 01

  Entered cDiseqc::Codes pointing at : E0 31 6B 01]

  In cDiseqc::Codes - returning a pointer 137345580 to :  W250 [E1 31

Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01

Sending Diseqc command: E1 31 6B 01

  Entered cDiseqc::Codes pointing at : E1 31 6B 01]

  In cDiseqc::Codes - returning a pointer 137345599 to :  W15 T

Received from diseqc->Codes(n) a pointer 137345509 to : E1 31 6B 01

Sending Diseqc command: E1 31 6B 01

 

The identical trace from 1.7.18 which works correctly looks like this: 

 

Diseqc command list found = t V [E0 10 38 F4] W500 [E0 31 6B 01] W250
[E1 31 6B 01] W15 T

  Entered cDiseqc::Codes pointing at : E0 10 38 F4]

  In cDiseqc::Codes - returning a pointer 137333177 to :  W500 [E0 31

Received from diseqc->Codes(n) a pointer 137333125 to : E0 10 38 F4

Sending Diseqc command: E0 10 38 F4

  Entered cDiseqc::Codes pointing at : E0 31 6B 01]

  In cDiseqc::Codes - returning a pointer 137333196 to :  W250 [E1 31

Received from diseqc->Codes(n) a pointer 137333125 to : E0 31 6B 01

Sending Diseqc command: E0 31 6B 01

  Entered cDiseqc::Codes pointing at : E1 31 6B 01]

  In cDiseqc::Codes - returning a pointer 137333215 to :  W15 T

Received from diseqc->Codes(n) a pointer 137333125 to : E1 31 6B 01

Sending Diseqc command: E1 31 6B 01

 

I have tried to revert cDiseqc::Codes in 1.7.19 to the 1.7.18 version
but the extent of the changes introduced to 1.7.19 in this area
eventually defeated my limited C++ skills. In doing so I have learnt and
read a lot and it appears that there are some pitfalls in returning
'const' values. I suspect that this is the problem here but can't be
sure.

If someone could have a look at this and suggest how to fix it, it would
be much appreciated.

 

Thanks,



Mark.

 

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

Re: [vdr] Diseqc problems with VDR1.7.19

[Hawes, Mark]

Just looked at the trace I sent in my initial post and realised that I
had selected a Diseqc command that I had modified while trying to
diagnose the situation so my annotations < > were a bit misleading.

The following should be less confusing: 

Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250
[E1 31 6B 04] W15 T

Diseqc action = 1

Diseqc action = 3

Diseqc action = 7

Sending Diseqc command: E1 31 6B 04 < Wrong, should be E0 10 38 F4 >

Diseqc action = 7

Sending Diseqc command: E1 31 6B 04 < Wrong, should be E0 31 6B 04 >

Diseqc action = 7

Sending Diseqc command: E1 31 6B 04

Diseqc action = 2

Again, the final Diseqc command has been sent three times, not the three
commands in the sequence they appear in the command list.

Apologies for the confusion.

 

Mark. 

 

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

[vdr] Diseqc problems with VDR1.7.19

[Hawes, Mark]

Hi,

 

Since upgrading to VDR 1.7.19 I have experienced problems with Diseqc.

 

My diseqc configuration uses command strings which contain 3 code sets:
a diseqc switch command, a diseqc go to command, and a repeat goto
command.

 

Since upgrading to VDR 1.7.19 it appears that the only code set sent is
the last one, but it's sent three times.

 

To demonstrate this I have put some trace in cDvbTuner::SetFrontend
within dvbdevice.c which traces the complete diseqc string, the diseqc
action, and for diseqc codes - the actual diseqc code sent. It produces
the following output:

 

Diseqc command list found = t v [E0 10 38 F4] W500 [E0 31 6B 04] W250
[E0 31 6B 04] W15 T

Diseqc action = 1

Diseqc action = 3

Diseqc action = 7

Sending Diseqc command: E0 31 6B 04 < Wrong, should be E0 10 38 F4 >

Diseqc action = 7

Sending Diseqc command: E0 31 6B 04 < Wrong, should be E0 31 6B 04 >

Diseqc action = 7

Sending Diseqc command: E0 31 6B 04

Diseqc action = 2

 

The same trace in vdr 1.7.18 shows the correct codes being sent in the
correct sequence.

 

I note that some work was done in this area for 1.7.19 but my C++ skills
are a little weak to diagnose the problem any further.

 

Can anybody throw some more light on what's going on?

 

Thanks,

 

Mark.

 

 

 

 

 

 

Mark Hawes
Senior Project Manager

Fujitsu Australia Limited
825 Bourke Street, Docklands VIC 3008, Australia
T +61 3 9924 3240 M +61 416 140 218 F +61 3 9924 3001 
mark.ha...@au.fujitsu.com  
au.fujitsu.com  

 

 

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