On 10/6/05, Daniel Kristjansson <[EMAIL PROTECTED]> wrote: > > > 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. >
I was of much the same opinion, largely because tzap reports widly varying values depending on which device I use. 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. > > > 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.) > 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 :-) > > > 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. > 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. > > > 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... Hmm. I was trying out timeouts of 30 seconds and beyond, but no joy. I went back to the 0.18-1 branch, and transferred my recorded programs table backward into a fresh DB. All my cards work just fine with Myth again. If I find the time, I'll test newer builds on the trunk, and even look more deeply into things, but for the time being, I think I'll be on 0.18 > > -- Daniel > > _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
