[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
 component area (DVB). I'm sorry if I'm adding to those frustrations.



 "The big print giveth and the small print taketh away"

Ticket URL: <http://svn.mythtv.org/trac/ticket/1502>
MythTV <http://www.mythtv.org/>

More information about the mythtv-commits mailing list