[mythtv] diseqc dst debug output

[Yeasah Pell]

Gnome42 Gnome42 wrote:
> Hi Yeasah,
>
> I am still trying to get reliable diseqc switching with lastest myth
> svn and kernel. I have hacked a retune into svn based on a timer in
> order to be able to switch ports. I also had to make a change to
> diseqc.cpp so that the retune would actually send a command to switch
> (as shown below).
>
(I hope you don't mind if I cc the reply to the list, I ended up saying 
some stuff about retuning that I'd like to have on list distribution):

First off, about the patch -- the process of a retune wasn't originally 
designed to resend diseqc -- if you want that, the easiest thing would 
be to call the diseqc Reset() method at the time of retune (that method 
doesn't actually issue any diseqc reset commands, it just invalidates 
any current state, so that all diseqc commands will be resent the next 
time an execute is done; similar to what you've done in the patch, but 
for all devices, not just switches) Basically what you should do is call 
diseqc_tree->Reset() from dvbchannel during a retune (before the 
diseqc_tree->Execute()), then the patch below won't be necessary, and it 
will also resend rotor commands if they are pending, as well as 
resending the LNB voltage command.

It looks like a number of people are still dependent upon retuning for 
purposes other than what you'd expect to be the application to have to 
deal with. All DVB cards that I know of (except the dst cards with older 
HW tuning driver) simply take the tuning parameters and will continue to 
search for signal even if there's no lock at the time that the tuning 
request was made, so there should in theory be no advantage to issuing 
multiple tuning requests except on old dst cards.

For diseqc, it makes sense to repeat the commands, since the 
communications medium of diseqc messages is unreliable and unconfirmed, 
but the idea is that you should be able to do whatever it takes to make 
sure the individual command is successful at the time you are first 
sending it -- when the diseqc command routine finishes we should have 
confidence that the command was successfully received by the remote 
device, or else fail the tuning sequence. In terms of making changes to 
improve switching reliability, I want the changes to go in at that 
level, not to just blindly re-do everything until it works.

The diseqc repeat stuff is of course designed to deal with the 
unreliability of the diseqc network itself. Anything else seems like it 
must be unreliability of the dvb drivers, and it really sucks to have to 
add retuning capability to compensate for bad drivers -- in fact, I'd 
much rather we fix the drivers than add retuning band-aids (which will 
significantly lengthen tuning time of course) Hence why retuning is so 
unpopular and keeps getting removed -- it shouldn't logically be 
required, and in principle it's just hiding other problems (and reducing 
tuning performance while it does so)

I can of course understand the desire to get something working, and if 
retuning is what it takes in some cases, well maybe it should be an 
optional feature, turned off by default -- since tracking down the real 
cause of the command unreliability could take a while, especially since 
my setup exhibits none of the unreliability.

-y
>
> --- diseqc.cpp  (revision 10994)
> +++ diseqc.cpp  (working copy)
> @@ -970,8 +970,10 @@
>         return false;
>
>     // determine if switch command needs to be sent based on last pos
> +    // Messes up retune() it seems?
>     if ((m_last_pos == (uint)pos) && m_children[pos])
> -        return m_children[pos]->Execute(settings, tuning);
> +        m_children[pos]->Execute(settings, tuning);
> +    //    return m_children[pos]->Execute(settings, tuning);
>
>     // perform switching
>     switch (m_type)
> @@ -997,7 +999,7 @@
>     }
>
>     // if a child device will be sending a diseqc command, wait 100ms
> -    if (m_children[pos]->IsCommandNeeded(settings))
> +    if (true || m_children[pos]->IsCommandNeeded(settings))
>     {
>         VERBOSE(VB_CHANNEL, LOC + "Waiting for switch");
>         usleep(DISEQC_LONG_WAIT);
>
>
> Here is some output from 2.6.18-rc4-mm3 with dst verbose=5.
> One 4 port switch connected to 2 lnbs.
>
> Initial tune is good:
> Aug 30 11:52:09 celery kernel: writing [ 00 08 04 e0 00 00 f0 24 ]
> Aug 30 11:52:10 celery kernel:  0x8 0x18 0x74 0x0 0x5d 0x2 0xd
> Aug 30 11:52:12 celery kernel: writing [ 00 09 ff 8b 01 00 00 6c ]
> Aug 30 11:52:12 celery kernel:  0x9 0x18 0x74 0x0 0x5d 0x2 0xc
> Aug 30 11:52:12 celery kernel: writing [ 00 08 04 e0 10 38 fa d2 ]
> Aug 30 11:52:12 celery kernel:  0x8 0x18 0x74 0x0 0x5d 0x2 0xd
> Aug 30 11:52:12 celery kernel: writing [ 00 08 04 e1 10 38 fa d1 ]
> Aug 30 11:52:12 celery kernel:  0x8 0x18 0x74 0x0 0x5d 0x2 0xd
> Aug 30 11:52:12 celery kernel: writing [ 04 8b 01 3a 2e 80 40 48 ]
> Aug 30 11:52:12 celery kernel:  0x8b 0x18 0x85 0x0 0x5d 0x2 0x75
> Aug 30 11:52:13 celery kernel: writing [ 00 05 00 00 00 00 00 fb ]
> Aug 30 11:52:13 celery kernel:  0x5 0x18 0x9d 0x0 0x5d 0x2 0xe7
> Aug 30 11:52:14 celery kernel: writing [ 00 05 00 00 00 00 00 fb ]
> Aug 30 11:52:14 celery kernel:  0x5 0x18 0x2c 0x0 0x5d 0x2 0x58
>
> Changed channel to different sat./switch port and failed:
> Aug 30 11:52:28 celery kernel: writing [ 00 09 ff 8b 01 00 00 6c ]
> Aug 30 11:52:28 celery kernel:  0x9 0x18 0x2c 0x0 0x5d 0x2 0x54
> Aug 30 11:52:28 celery kernel: writing [ 00 08 04 e0 10 38 f4 d8 ]
> Aug 30 11:52:28 celery kernel:  0x8 0x18 0x2c 0x0 0x5d 0x2 0x55
> Aug 30 11:52:28 celery kernel: writing [ 00 08 04 e1 10 38 f4 d7 ]
> Aug 30 11:52:28 celery kernel:  0x8 0x18 0x2c 0x0 0x5d 0x2 0x55
> Aug 30 11:52:28 celery kernel: writing [ 04 9a 01 3a 2e 80 00 79 ]
> Aug 30 11:52:28 celery kernel:  0x34 0x15 0x25 0x0 0x5e 0x2 0x29
> Aug 30 11:52:29 celery kernel: writing [ 00 05 00 00 00 00 00 fb ]
> Aug 30 11:52:29 celery kernel:  0x5 0x14 0xa8 0x0 0x5d 0x2 0xe0
> Aug 30 11:52:30 celery kernel: writing [ 00 05 00 00 00 00 00 fb ]
> Aug 30 11:52:30 celery kernel:  0x5 0x14 0xac 0x0 0x5d 0x2 0xdc
>
> retune kicked in and tuned the channel correctly:
> Aug 30 11:54:30 celery kernel: writing [ 00 08 04 e0 10 38 f4 d8 ]
> Aug 30 11:54:30 celery kernel:  0x8 0x14 0xac 0x0 0x5d 0x2 0xd9
> Aug 30 11:54:30 celery kernel: writing [ 00 08 04 e1 10 38 f4 d7 ]
> Aug 30 11:54:30 celery kernel:  0x8 0x14 0xac 0x0 0x5d 0x2 0xd9
> Aug 30 11:54:30 celery kernel: writing [ 04 9a 01 3a 2e 80 00 79 ]
> Aug 30 11:54:30 celery kernel:  0x9a 0x14 0x82 0x0 0x5e 0x2 0x6c
>
> Any clues in there?  Is there anything else I can provide that could 
> be useful?
>
> Regards,
>
> Shane