On Thu, 2005-10-06 at 23:43 +0100, Adrian Wilkins wrote: > On 10/6/05, Daniel Kristjansson <[EMAIL PROTECTED]> 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
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
