[mythtv] Ticket #1945: DVB-S/diseqc patch
mark.buechler at gmail.com
Fri Jul 21 02:52:08 UTC 2006
This is with two different switches connected to two different DV cards (one
of them being a Twinhan). I'll test more tomorrow.
On 7/20/06, Yeasah Pell <yeasah at schwide.com> wrote:
> Mark Buechler wrote:
> > Yeasah, I did notice a few times today something odd with your switch
> > code. The very first switch command sent (as the backend starts)
> > doesn't seem to work on either on my switches, or doesn't always work,
> > anyway. I'm wondering if your diseqc reset is throwing the switch for
> > a loop for a brief period. What's the wait time between switch
> > commands? Is this reset necessary? Tomorrow I'll test by taking out
> > the reset to see if that helps though this problem doesn't happen all
> > the time for me.
> > - Mark.
> The reset is there just to get everything into an initialized state --
> it only does it when the frontend device is first opened, as you say. It
> isn't strictly required, since all the devices should be explicitly
> reset to their desired values anyway, it's just in there to make sure
> everything is completely sane before proceeding.
> DiSEqCDevTree::ResetDiseqc is where the reset is done, you can look
> there for details on what exactly happens at reset time. Basically the
> reset delays are 100ms, and by default currently it power cycles the
> diseqc devices as well. It would be interesting to know if the situation
> improved if you disabled the power cycle (change it to call ResetDiseqc
> with a the hard_reset parameter set to false).
> Does this happen on more than one kind of DVB card, or have you only
> noticed it on one type so far? I think you have a couple of twinhan dst
> cards in your setup, don't you? I have a couple of patches outstanding
> for that driver, one of which has been accepted but doesn't yet seem to
> be in the main hg tree yet. One of them improves tone/power control, but
> more importantly the other one improves error reporting. Without that
> patch, failed commands would often not be reported to the application
> (and in my experience there are times when the driver won't successfully
> complete commands for extended periods of time, 100s of ms -- hence the
> relatively lengthy ioctl retry sequences in the diseqc code.) I could
> easily see that being part of the problem...
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev