[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