[mythtv] diseqc dst debug output

[Gnome42 Gnome42]

On 8/30/06, Yeasah Pell <yeasah at schwide.com> wrote:

> (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):
>
Sure, no prob.

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

OK, thanks for the info. The retuning patch was just a temp hack /
workaround, not meant to be integrated or anything.

> 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 agree totally, it is much better to address the root cause of the
problem and not using band-aids. I don't have much skill/understanding
of this stuff. So I was really only asking how I might be able to help
with debugging etc.

Thanks,

Shane