[mythtv] Current SVN DVB-S zapping problems (diseqc?)

[Yeasah Pell]

Simeon Simeonov wrote:
> For completeness: I was able to resolve my diseqc
> problem by two things:
>
> - delete the SetTone(false) from
> DiSEqCDevTree::Execute in diseqc.cpp and I have no
> idea why but there could be flaky thing for my type of
> cards (pure speculation on my side);
>   
That one is really interesting to be sure. You're supposed to turn off 
tone before doing diseqc (if it's on), to give a silence period between 
the continuous tone and the diseqc tone modulation. (Some cards/drivers 
do this automatically though) If you are using a universal LNB and the 
last tuning you did was for the high band, the tone will indeed be on at 
that time, so by not turning it off you're violating the diseqc spec. 
But hey, if it works. Maybe you should turn the tone *on* there instead 
of taking the line out, to make it consistent.
> - force resending the diseqc commands during retune by
> inserting  diseqc_tree->Reset() before
> diseqc_tree->Execute() in dvbchannel.cpp
>   
When you say "retune", you mean the single rotor-completion retune, or 
some other retune mechanism you've added?
> Retuning by default does two things: sets the correct
> tunning voltage if it was overwritten for the rotor
> and sets once again the tone for tone controlled LNBs.
> It looks like for my card it is important to set the
> voltage in order to tune. So if my tunning voltage is
> 18 volts then by default it will not be set a second
> time. By forcing setting the voltage each time I had
> partial success when switching from one source to
>   
Actually it should change the voltage back whether you call Reset() or 
not -- the first thing Execute() does is call ApplyVoltage, which goes 
and gets the current desired voltage (once the rotor is deemed complete 
that will go back to whatever value it was before it was overridden to 
18V), and calls SetVoltage, which checks to see if that voltage is in 
fact different from the last voltage command that was sent, and sends it 
if it's different. It's possible that there's a bug in there of course, 
but I've never had a problem. It should be easy enough to tell from the 
logs if it's doing the final voltage change correctly or not without 
Reset(), it logs every time it changes the voltage.

It always sets the tone at the very end of every Execute() call as well 
(for universal LNBs) -- it doesn't bother to figure out if it's already 
in the desired state. So Reset() wouldn't affect the tone either.

So I think (unless something's amiss) that the only thing calling 
Reset() changes in the context of a rotor completion retune is that the 
diseqc commands get resent.
> another. But by repeating the whole diseqc sequence I
> had no problems switching between sources. My guess is
> the since I have a switch behind a rotor first the
> rotor command is sent and it starts rotating. Perhaps
> this generates some noise in the line and that is why
> the switch command that is sent at that time sometimes
> does not succeed. 
>   
But also, since you removed the initial tone off command, the second 
diseqc command sequence is guaranteed to be surrounded by tone (for high 
band frequencies, anyway), whereas the first command might not be. It 
certainly seems strange, but it's possible that your setup needs to have 
the tone on before diseqc in order for it to work, and maybe *that's* 
what repeating the diseqc commands accomplishes.

I guess if switching is less reliable for low band transports, that's 
good evidence toward that theory.

Thanks for the report!

-y