[mythtv-commits] Ticket #1502: DVB API requires usleep after certain calls to get reliable tuning on certain drivers (esp Nova-T).
MythTV
mythtv at cvs.mythtv.org
Mon Mar 13 21:05:46 UTC 2006
#1502: DVB API requires usleep after certain calls to get reliable tuning on
certain drivers (esp Nova-T).
--------------------------------+-------------------------------------------
Reporter: dscoular at cisco.com | Owner: danielk
Type: patch | Status: closed
Priority: minor | Milestone:
Component: dvb | Version:
Severity: medium | Resolution: fixed
--------------------------------+-------------------------------------------
Comment (by dscoular at cisco.com):
Hi Daniel,
Wow! that was speedy work... however I think there are a few problems with
this patch.
1) the delay used by scan.c is 200000 microseconds which is equal to 0.20
seconds, not the
2 second delay you have set as the default.
2) You have made the usleep only apply if we detect a frontend name of
"!DiBcom 3000P/M-C DVB-T"
which ignores the fact that this usleep is a catch all for ALL cards.
That being said, if
you insist that it is conditional... can the DVBTuningDelay spinbox
also be conditional
(just curious really) ?
And finally just to really drive you nuts...
Having got reliable tuning on my Nova-T I decided to turn my attention to
my !AverMedia !AverTV
DVB-T USB 2.0 card... and was pleased to find that after a history of
never tuning on either
0.18.1 or 0.19 (but again perfect on tzap) two of my six channels were,
indeed, tuning...
so perhaps the timeout was working some magic there too.
However, the really interesting thing I found after spending 3 hours
trying to get the other
4 channels working was that the values in dtv_multiplex were really
screwed up when compared
with any of my channels.conf scan.c based scans. When I manually fixed the
dtv_multiplex to more
accurately reflect the channels.conf output... tuning started working
perfectly on all channels
on both cards. It seems the Nova-T can handle more auto or incorrect
settings than the !AverTV
card... however, both did improve with the timeout code.
What I now want to do tonight (Sydney time) is rip out my usleep code and
see how tuning fairs
with more accurate dtv_multiplex data. The data had been a result of a
fresh full scan ignoring
timeouts. I'd also tried loading the channel.conf but that seemed to
produce some bad data too.
Tuning with known good data will let me really determine the value of the
usleep code. I'm
sorry I didn't realise that the dtv_multiplex data wasn't accurate as this
sets everything
in a new light.
I still think that Manu's point about mimicking scan.c standing the best
chance of reliable
tuning across the broadest collection of cards, in spite of the dumbness
of an API that allows
this, is a fair and reasonable point. I'll be able to confirm or refute
this tonight.
Anyway, thanks again for an amazing responsiveness in what must be a very
frustrating
component area (DVB). I'm sorry if I'm adding to those frustrations.
Cheers,
Doug
--
"The big print giveth and the small print taketh away"
--
Ticket URL: <http://svn.mythtv.org/trac/ticket/1502>
MythTV <http://www.mythtv.org/>
MythTV
More information about the mythtv-commits
mailing list