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

[Daniel Kristjansson]

On Thu, 2005-10-06 at 14:39 +0100, Adrian Wilkins wrote:
> Reply from linuxtv list about MythTV and DVB-T problems that have been
> observed with USB units. Any comments?
> 
> On 9/30/05, Patrick Boettcher <patrick.boettcher at desy.de> wrote:
> > I read the ticket, but I never used MythTV so far, anyway, I think you are
> > facing "normal" problems:
> > 1) IMHO Myth should not rely on the signal-strength and
> > signal-to-noise-ratio.
MythTV does not rely on these, it only monitors them for the UI.
They aren't useful for determining lock because they aren't
normalized, but they can be useful for adjusting your antenna.

> > devices MythTV should rather monitor the LOCK-status
This is what it does. It relies on the LOCK status for 
signal lock determination, then it waits for the PAT, and
then it waits for a specific PMT on the PID specified in
the PAT.

Sometimes waiting for the LOCK isn't useful either because
the driver doesn't report a lock for a marginal channel,
but I don't know of any DVB API call to lower the LOCK
threshold. Would monitoring the BER and beginning recording
without a LOCK status be safe? (I must mention that I'm
not in a DVB country, I'm just maintaining the code.)

> > 2) USB1.1 devices (and USB2 devices running on a USB1.1 hub) that are
> > using BULK transfers for MPEG2-TS transfer are facing a problem. The
> > bandwidth of USB1.1 is not enough for receiving the complete transport
> > stream of a DVB-T channel (which is about 12 to 16 MBit/s). That's why all
> > DVB devices on USB1.1 using a PID filter in hardware to just get the
> > packets with the requested PIDs.
Interesting.

> > Problem:
> > If only a PAT is requested it will take a quite long time to fill the
> > BULK-transfer buffer. The BULK-URB won't return to the driver (and thus to
> > the demux/section-filter) unless it is full. (That's why Malc has to use
> > -5 as a parameter of dvbscan to get something (because the PID 0x10 (NIT:
> > network information) is only repeated with a larger interval and it is
> > small too)).
> > Unfortunately I had problems by reducing the buffer-size of URBs (so that
> > it won't take too long to get the URBs back)... which would be a solution.
> > This problem does not exist for USB1.1 device using isochronous transfers
> > for MPEG2-TS delivery.
So the problem is that the devices try to fill some large buffer
with PAT's and later PMT's before it will return data, hence the
long delay? That sounds like it needs to be solved in the driver,
we don't know about any large streams to enable until we see the
PMT; especially during a channel scan. We can't enable all of 
streams on USB 1.1 devices because USB 1.1 can't handle transferring
the whole data stream.

BTW Adian, it this is the problem, recordings should work now
because we now wait for the length of the program for a lock...

-- Daniel