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

[Daniel Kristjansson]

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.

> > 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 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.)

> > 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.

-- Daniel