[mythtv] [mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T).

Daniel Kristjansson danielk at cuymedia.net
Thu Mar 16 14:46:05 UTC 2006


On Thu, 2006-03-16 at 04:13 +0400, Manu Abraham wrote:
> Doug Scoular wrote:
> It depends on the driver how this averaging is done, so the app should 
> probably handle the value that it get's through, but it doesn't hurt to 
> average the values either. But there are cards where this is totally 
> meaningless.
Yup, the averaging is in my long term todo, it just doesn't have a
terribly high priority because it doesn't serve any purpose in MythTV
yet. Many cards don't even report these values.

> For testing whether the tuning has succeded, checking for FE_HAS_LOCK 
> should be sufficient.
This is the only thing we use to detect the signal quality for DVB drivers.
Then we look for the MGT/VCT or PAT/PMT depending on the tuning params
we have, that part is the more important part of the signal monitor
for tuning. Part of the problem is that we don't look for NIT/SDT
so we can tune to the wrong transponder... There is a ticket for this
and a MythTV user volunteered a DVB-land locate machine for me to test
fixes for this, but I'm maxed out on my wife enforced MythTV hours
per week, so it may take a while for me to get to it.

> >     I think the delay is also needed to determine whether
> >     the tuner has reliably achieved FE_HAS_LOCK.
> Yes. It can be considered as a Factor Of Safety. All applications do 
> abide by this except for MythTV. IIRC Marcus Metzler did send a pacth to 
> fix this issue, but that patch was thrown away.
I don't recall any patch from him for this issue. I've only been
maintaining the DVB stuff for a few months so it may have been
before I started tracking DVB patches. There was a period after
Taylor Jacob ran out of time and before I picked it up, if it was
sent during that period it would have fallen into a black hole.

> >     I'm beginning to think the signal monitoring is fairly
> >     meaningless... 
> Signal monitoring is meaningless on some cards, since different tuners 
> have different values etc, and there is not much of a standardization 
> there, but this will change in the future.
The monitoring of the signal & s/n values is mostly to support antenna
adjust mode (F7). But it is reported when changing channels so that
the user has some idea of what the normal values are for his driver.
I'd love to see some standardization in this area. API 4.0 is already
an improvement, since the int16_t -> uint16_t change we no longer
see drivers that report decreasing negative values for a better signal.
The well coded drivers mostly used the safe 0..2^15 range anyway, so
it looks like all cards are reporting somewhat sane values now.

> >     I might also look over how the DVR project deal with tuning
> >     on DVB cards... 
> You can take a look at scan, VDR, Mplayer, VLC or anything. All the 
> applications out there tune properly except for MythTV.
"Everyone else is doing it" doesn't make it right. I would much
rather have a 'maintain lock for x msec' threshold rather than
a have lock at 'magic moment y' threshold. We actually used to
use the same tuning regime as those programs, and it resulted
in shads of zero-length recordings... Now zero-length recordings
are only happening for Nova-T and DVB-S people, so from where
I stand (admittedly with non-broken cards) it looks like an
improvement. That doesn't mean I don't want to improve the
tuning, it just means I'm sceptical of modeling our tuning
on these forms of magic moment tuning we've abandoned after
their utter failure in MythTV.

> In fact Marcus Metzler had sent a patch to fix this issue.
> Any ideas what happened to it ?
I tried searching the archives and didn't find anything for this.
I have applied patches from him, so he's not a total unknown
around here...

-- Daniel



More information about the mythtv-dev mailing list