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

[Doug Scoular]

Hi Daniel et al,

Danielk wrote:
 > I believe the sleep after FE_READ_STATUS in scan is just to give the card
 > some breathing room. We do the same thing in SignalMonitor::MonitorLoop()
 > usleep(update_rate * 1000);

    Ah, okay I'll play with the update_rate.

Danielk wrote:
 > The BER and UNC are mostly meaningless the way we read them.
 > These are cumulative values, so we should throw out the first
 > read and we should also sum these over a time period and report
 > errors seen in that period, but we do neither. There is a comment
 > in DVBSignalMonitor::UpdateValues() about this...

    Yes, I read that and I really don't care that much
    about BER/UNC stats... just whether FE_HAS_LOCK is
    reliable.

Danielk wrote:
 > We trust the FE_LOCK from the DVB drivers for tuning and these
 > values aren't anywhere near as useful as signal and s/n for
 > antenna adjustment so implementing the normalizing code is
 > pretty low priority for me.

    I understand... and as I said it is FE_HAS_LOCK that
    I really care about too.


Danielk wrote:
 > I think you may have misinterpreted what they said. A delay is needed
 > for the cumulative values to look less random, but you can and should
 > sum these values over a larger period than the between read delay.

    I think the delay is also needed to determine whether
    the tuner has reliably achieved FE_HAS_LOCK.

Danielk wrote:
 > There is a constant in tv_rec.cpp:
 > /// How many milliseconds the signal monitor should wait between checks
 > const uint TVRec::kSignalMonitoringRate = 50; /* msec */
 > Set this to 250 milliseconds to simulate the code you had in
 > the original patch.

    Cool, I'll check that out too.

Danielk wrote:
 > But you are talking about a huge cumulative delay here, I'm afraid you
 > might just be getting more successful tuning because you are sleeping
 > for hundreds of milliseconds. Perhaps this driver never reports anything
 > but "successfully tuned", so the delay is just waiting until this is
 > true in the general case, so even if you add all these delays it will
 > never tell you there is anything wrong with the signal which makes the
 > signal monitoring pretty useless on the whole...

    I'm beginning to think the signal monitoring is fairly
    meaningless... but at least people can use it as a very, very
    rough guide (signal anyway). I'm thinking that we may only
    need the 200,000 microsecond usleep on the first FE_READ_STATUS
    before checking for FE_HAS_LOCK.

    I'll do some more experimentation tonight and see if I can
    come up with a new prototype patch... ok ?

    I might also look over how the DVR project deal with tuning
    on DVB cards... ah... actually I'm off to the pub tonight
    so it might be a day or so till I have some results or a patch.

    Cheers,

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