[mythtv] RetuneMonitor generates significant load with DVB cards without hardware i2c support

Janne Grunau janne-mythtv at grunau.be
Tue Jul 25 23:55:04 UTC 2006


On Wednesday 26 July 2006 00:29, Yeasah Pell wrote:
> >1. don't call RetuneMonitor that often, 2-3 times per second is
> > probably enough. This may slowdown tuning for rotors.
>
> I think that's fine in principle. No big deal to wait a few hundred
> extra milliseconds when you're already waiting multiple seconds for a
> rotation.

I'm a little reluctant to add a timer to a read loop.

> >2. disable the RetuneMonitor after IsAllGood() is true. This removes
> > the functionality but if I understand it correctly the main feature
> > of the RetuneMonitor is to make tuning more reliable with rotors
> > and diseq-switches. Currently the eitscanner is more reliable than
> > live-tv/recordings since it has a continous LOCK check.
>
> In the case where a multiplex has enough info to validate
> definitively by table match (netid, tpid, sid), it will hit IsAllGood
> immediately (to start the table monitor), but you don't want to shut
> off the retune monitor yet because it could still complete before a
> table match happens.

I think you looked at the wrong IsAllGood(). 
DTVSignalMonitor::IsAllGood() returns only true if all of the tables 
(PMT/VCT/SDT...) we are waiting for are actually matching. So we can be 
sure that the tuning is correct then DTVSignalMonitor::IsAllGood() 
returns true.

> However, consider this --
>
> [removing LOCK monitoring from RetuneMonitor]
>
> The only downside I can see to removing that would be that you would
> potentially fail to tune under the following condition, which seems
> rare enough to not worry about:
>
> 1) A rotor is used with a dst card.
> 2) The rotor time estimate was too short (i.e. the angular speed
> configuration for the rotor is set too high), so tuning began while
> the dish was still in motion -- but it'd have to be more than a few
> seconds too short, because the dst waits at least a few seconds while
> attempting to acquire a signal.

I think these two cases are not rare enough to remove the functionality. 
My second proposal should work and I'm now convinced that it is a good 
solution. I'll prepare a patch tomorrow.

Janne


More information about the mythtv-dev mailing list