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

[Janne Grunau]

On Wednesday 26 July 2006 02:22, Yeasah Pell wrote:
> >>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.
>
> Hey, it was your idea.

Yeah, but I wasn't convinced it was a good one. Now I'm sure that the 
second is better.

> >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.
>
> Right, sorry, I misunderstood. I suppose there's really no reason to
> keep the rotor object in the loop after a lock has been confirmed via
> tables, but it's better if the rotor object at least gets informed of
> that so it can update its internal state to know that it is pointed
> correctly at that moment. I was originally intending to add a feature
> where it would be able to measure the rough error of approximated
> rotation speed based on this, and while that isn't in there, I'd like
> to add it eventually. Probably calling the retune monitor one last
> time after IsAllGood() is flagged would be sufficient for this
> though.

This should be possible however see below.

> >>1) A rotor is used with a dst card.
> >>2) The rotor time estimate was too short..
> >
> > 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.
>
> Perhaps I wasn't clear

Or I misunderstood. I read conditions not condition. And it is rare 
enough and most users will understand if you tell them that they should 
correct their rotor configuration.

> I'd really much rather we remove the periodic retunes at this point
> -- it's no longer needed, there never was an *especially* compelling
> reason for it, and it will probably mask problems -- it's basically a
> crutch that will allow people to get by with bogus configurations.

This is even better than deactivating the RetuneMonitor() after all 
tables match. Waiting for your patch then.

Janne