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

Yeasah Pell yeasah at schwide.com
Tue Jul 25 22:29:32 UTC 2006


Janne Grunau wrote:

>Hi,
>
>The cause is the FE_READ_STATUS ioctl in RetuneMonitor. It blocks for 
>approximately 10ms on cards with a cx88 or bt8xx pci bridge and the 
>pluto2 device. These devices have no hardware i2c support. For the cx88 
>it's just not implemented yet. They use i2c bit banging instead.
>
>This wouldn't be a problem if the signalmonitor is only for tuning 
>checks before channel changes. But it isn't that good for the active 
>eitsccanner.
>
>I see two options to reduce the load:
>
>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.

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

However, consider this --

Just for rotor stuff, the retune monitor doesn't need to do a 
READ_STATUS at all. In fact, that's only in there for the benefit of 
cards that don't retune on their own should they not acquire lock or 
lose lock later, but the only card that I'm aware of that behaves like 
that (dst frontend, normally behind bt8xx bridge) was recently upgraded 
to use software tuning by default, so that's no longer necessary with 
the latest DVB drivers.

Given that the RetuneMonitor() always does a retune on rotor completion 
anyway, I'd be ok with removing the "retuning for lock loss" 
functionality entirely, which should solve this problem completely 
(since no READ_STATUS would happen at all)

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.

-y



More information about the mythtv-dev mailing list