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 <[EMAIL PROTECTED]> 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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
