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

Manu Abraham abraham.manu at gmail.com
Thu Mar 16 16:35:18 UTC 2006


Daniel Kristjansson wrote:
> 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.
>   

You are right, we are looking at this aspect, but this involves some 
changes like getting math operations into kernel/moving frontend drivers 
out to userspace. We have some thoughts on this, but don't bet on it, 
since there are quite some issues to be considered.

And when this is done, in most cases you wouldn't have to do the 
averaging, the driver will do the averaging according to the specs from 
the chipset vendor.

Another one of the reasons why drivers are in such a state is that many 
drivers are Reverse Engineered , since vendors don't release 
specifications / information on them. But for some of them due to 
certain reasons some things cannot be implemented in kernel as it is.

We are looking at userspace libraries to fix issues like this, so that 
all such information like this can be contained in them such that 
applications  do not have to be bothered by issues like this. It will 
not be too long for them.

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

Hmm.. I was talking to Ralph Metzler, he told me that Marcus Metzler 
sent you guys a patch to fix the issue properly. If Marcus sends you a 
patch i can assure you that you that you can use that patch as it is.


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

AFAIK, the values are simply mapped and on different hardware it has 
different meanings. It might need further processing to display 
something really sane enough.


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

I understand what you are saying, but if you say that if you want 
drivers to be fixed, then it would be as good as talking terms to the 
kernel folks to have certain features in the kernel. So IMHO if you 
think that things should remain broken for that period till LK folks 
agree, then MythTV will remain broken for all those time.

IMHO you guys should adapt to something what's acceptable to the rest of 
the world for the time being and later on use the stuff whatcomes out as 
a good solution. First fix the immediate problem, then go for the finer 
fix. Don't wait for the fine fix to be your first and final fix.


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

I will ask him to send again, in case you guys are interested.


Manu



More information about the mythtv-dev mailing list