[mythtv] Fwd: [linux-dvb] USB DVB-T tuners and MythTV

[Adrian Wilkins]

On 10/11/05, Daniel Kristjansson <danielk at cuymedia.net> wrote:
> On Thu, 2005-10-06 at 23:43 +0100, Adrian Wilkins wrote:
> > On 10/6/05, Daniel Kristjansson <danielk at cuymedia.net> wrote:
>
> > By far the best indication of a good signal has been a *steady* (not
> > high) value of SNR. Variation in this value spells doom, a steady
> > value, even with a low signal, produces a good picture.
> I think the various monitoring values all rather random across cards.
> Maybe signal was intended to be the normalized one that works across
> all cards. But instead the only halfway reliable thing across cards
> is LOCK, and that is pretty much calibrated to the reception for
> whoever wrote the driver.
>

If tzap always returns the status from the driver, I'd say that
FE_HAS_LOCK isn't even reliable (unless my USB boxes internally tune
faster than my PCI card). FOr at least one USB tuner, it was returning
that value for the first row of output, which does not have the same
values for the other parameters that the subsequent rows do.

> > > without a LOCK status be safe? (I must mention that I'm
> > > not in a DVB country, I'm just maintaining the code.)
> > Meh. I'd do it, but I'd need to scrape together a dev environment for
> > linux. And the small matter of an understanding of C++ beyond theory
> > :-)
> The dev environment for MythTV is basically just gcc, a proper
> QTDIR, and the headers for the various libraries. The C++ I can't
> help you much with, but we are trying to make the backend stuff not
> use all the fancy Qt stuff like signals/slots/timers, but instead
> just "plain C++".
>

I was referring more to a nice IDE ; I've obviously got the right env
to compile Myth, or it wouldn't work. I can't grok big bodies of code
in a language I've never coded in without syntax markup and member
listing.  :-)

> > I was going to have a look at the streams with some of the DVB stream
> > diagnostic tools you can get for windows and linux. But time is always
> > such a difficult thing to find.
> My guess is that at least on tunes after the first one you could speed
> up DVB-over-USB tuning of on-air channels by simply caching the PMT
> video pid and adding that with ATSCStreamData::AddListeningPID() to the
> signalmonitor's pids in TVRec::SetupSignalMonitor(); that should add
> enough bulk to fill up the bulk transfer buffer and initiate the data
> transfer to the PC. It is also possible to add the PMT pids from the
> last tune to the listening pids and get your PMT in addition to the PAT
> on the first bulk transfer (assuming the PMT pid hasn't changed, if it
> has you will still have to wait for the second bulk transfer.)
>

Ah, so the signal monitor is waiting for the list of PIDS before it
asks for the PID allocated to the video stream? So it's a catch 22 ;
the video stream is needed to bulk out the transmission enough to pass
the PMT, but the backend won't ask for it until it can confirm the PID
from the PMT block?

So, caching the PMT PID for the video stream on that channel? That
would make sense, and especially if the backend would make a
background pass over the tuner without you having to tune that channel
at least once. Or even caching the PIDs from a different tuner (if it
used my PCI card, it would never have to wait 40 seconds).

> > > BTW Adrian, it this is the problem, recordings should work now
> > > because we now wait for the length of the program for a lock...
> > Hmm. I was trying out timeouts of 30 seconds and beyond, but no joy.
> Well for scheduled recording the timeout is on the order of 30 minutes...
> I've been told 40 seconds is common for DVB-over-USB.
>

My box is used during the day mostly by my non-techie Mother-in-law,
who wouldn't understand waiting 40 seconds for a channel to tune. And
quite frankly, waiting 40 seconds for a picture is something I'd
consider a bug (in one piece of the software stack or another). Given
that I can yank the USB cable from the DEC2000T and have a standalone
STB that tunes and shows a picture in less than 3 seconds, and that
the Myth 0.18-1 isn't a lot slower, I guess my point of view is I'd
rather have a "sloppy" implementation that doesn't do signal
monitoring, but works just fine bar a couple of quirks like channels
going off air that I have to compensate for with a shell script, or a
"correct" implementation that cripples two thirds of my tuners, I'd
rather have 0.18 than the current HEAD of trunk.

Monitoring for PMT is just fine, but what better indication is there
of correct tuning than a big fat MPEG2 stream crossing the bus?