[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
Mon Mar 13 22:05:46 UTC 2006


On Mon, 2006-03-13 at 21:05 +0000, MythTV wrote:
> #1502: DVB API requires usleep after certain calls to get reliable tuning on
> certain drivers (esp Nova-T).
> Comment (by dscoular at cisco.com):

>  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.
Sorry, I miscounted the zeros, I'll fix this soon.

>  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.
I don't want to enable the hack by default because doing so fails to
encourage driver writers to fix their drivers. I think part of the
problem is simply that the driver writers don't know their drivers
are broken because the DVB utils use these hacks by default. Plus,
this hack would down tuning for those of us with working drivers.

>  That being said, if you insist that it is conditional...
>  can the DVBTuningDelay spinbox also be conditional (just curious really) ?
Sure, but I figured exposing it would let users discover the delay
needed for the driver they are using, and perhaps report it to the
developers...

>  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...
>  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...
I've recently enabled new scanning code in SVN, it works great here
for ATSC, but there appears to be a problem with enabling the SDT
pid monitoring (pid 0x11, I believe). If you could fix that, it might
fix the transport problem you are experiencing. You must delete
existing transports before doing a scan however, otherwise the old
transports will be reused.

-- Daniel



More information about the mythtv-dev mailing list