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

Yeasah Pell yeasah at schwide.com
Wed Jul 26 00:22:15 UTC 2006


Janne Grunau wrote:

>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.
>  
>
Hey, it was your idea. I was just saying that I didn't think it was 
going to cause any problems, but that I'd rather remove the 
FE_CAN_RECOVER-based retunes (that I added very recently, btw -- nobody 
should be dependent on that yet) instead.

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

>  
>
>>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.
>  
>
Perhaps I wasn't clear -- it has to be all of these things happening at 
once. You have to have a dst card, an older broken driver, AND a 
misconfigured rotor such that it gets the rotation time wrong by at 
least 2-3 seconds. There are two solutions to this very specific 
situation other than leaving in the retunes -- fixing the rotor 
misconfiguration, or upgrading to a non-broken driver.

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.

-y



More information about the mythtv-dev mailing list