[mythtv-users] DVB-T tzap versus mythtv 0.19

[Doug Scoular]

Hi All,
    I've upgraded to release-0.19-fixes (9277) and am still
    having problems with channel tuning and the Nova-T.

DanielK wrote:
 > The Nova-T DVB driver hasn't been fixed yet. Until it is, I can say 
it's broken :)

    I bow to your greater knowledge... however, I've asked Patrick 
Boettcher on
    the linux DVB mailing list to confirm or refute this problem being 
with the
    Nova-T driver. Hope this is okay.

    The 0.19-fixes (9277) release does seem a little faster to change 
channels (not that
    this is my concern in this thread) but it is just as unreliable at 
tuning. I get
    amazingly incoherent results from the OSD signal monitor... sometimes
    giving me terrible figures for BE (65535), sometimes BE (0), 
sometimes I get
    No Lock, sometimes partial, sometimes full... and every combination of
    the above can randomly lead to a picture or not. Sometimes I get a
    picture but the frontend no longer accepts input. Also, I occasionally
    get a completely blank OSD signal monitor timeout dialog (this is
    new to me post 0.19-fixes).

    I'm going through the code right now trying to figure it out. It appears
    0.18.1 simply waited for FE_HAS_LOCK. 0.19.1 is much more complex;
    interrogating the card via ioctls for the features it supports and then
    using these in combination to see if they are "allgood".

Neil wrote:
 > If you're jumping into the code in the near future, maybe you could 
point
 > me to the right place as that was pretty much *my* next stop. I want 
to try
 > to find out if there's anywhere around the start of DVB recordings that
 > *doesn't* log if it's not working. I've not touched the Myth code 
before ...

    Me neither but here's what I've gleaned so far... please correct me
    if I'm wrong...

    It looks like tv_play.cpp calls TV::RunTV which starts an event loop
    running. Each time the loop iterates it calls TV::UpdateSignalOSD.
    UpdateSignalOSD calls SignalMonitorValue::Parse which uses extra
    "SIGNAL" event data to determine what card parameters are to
    be monitored.

    Oops, maybe I'm getting ahead of myself... when we
    change channels the event triggers a call to TV::ChangeChannel
    which in turn calls TV::SetChannel. This adds a tuning request
    to a queue and waits for it to tune. TVRec::HandleTuning
    in tv_rec.cpp deals with this request.

    TVRec::HandleTuning, in turn, calls TVRec::TuningFrequency.
    This figures out the channel name, and possibly the
    input name we need to pass to "channel" and then calls
    channel appropriately. Then it adds any filters and sets any
    video capture attributes that need to be set.

    The card specific signal monitoring is started. When the
    signal monitor determines that all monitored card parameters
    are "good" then it switches the channel and stops the OSD
    monitor. I think it is the combination of what parameters are
    being monitored and the IsAllGood() method that is the
    crux of the code. The IsAllGood method ensures that all the
    monitored card parameters meet the IsGood() method's
    criteria of what is good. The IsGood method checks a
    value against a previously set threshold.

 > Have a read through the archives, look for Aafloy's posts.
 > The code in question is in dvbchannel.cpp, mostly in the
 > wait_for_backend() function.

    Thanks for the pointer... I did look through Kenneth's posts
    but I'm pretty out my depth now.

    Ooh... my head hurts. I want to debug what the thresholds are
    and how they are being combined in IsAllGood()... but I need
    to lie down now :^/

    Anyway, I'll get back to the thread on what I find (if anything).

    Cheers,

    Doug