... > Ah, so the signal monitor is waiting for the list of PIDS before it > asks for the PID allocated to the video stream? My guess at what the current flow is something like: a) The channel / multiplex tuning request is made using the service identifier b) The signal monitor thread is invoked c) for DVB-T the monitor waits for a pat and pmt to confirm that the service is available and then sets up the pid filters as defined in the PMT d) The front end now waits for confirmation that the correct pat/pmt have been seen before showing the filtered stream
at 7448 - d) wasn't enforced so that if you bypassed the PAT/PMT check it worked - the front end showed what it got - scanning could be sorted by importing channels.conf :) ... > My box is used during the day mostly by my non-techie Mother-in-law, > who wouldn't understand waiting 40 seconds for a channel to tune. And > quite frankly, waiting 40 seconds for a picture is something I'd > consider a bug (in one piece of the software stack or another). Given .... again at 7448 the dec was tuning in 3-4s - marginally faster in fact than my PCI card! > Monitoring for PMT is just fine, but what better indication is there > of correct tuning than a big fat MPEG2 stream crossing the bus? might be the wrong stream? Although the above worked for on-air channels the new off-air behaviour (which we need in the UK) didn't - obviously! :) Experimenting a little and trawling the threads I think the story is: The signal monitor implementation is very clean/elegant, but it does rely on being able to get the DMX_PES_OTHER packets output on the dvr stream. doing this means the monitor's job is very straightforward - it just has to watch that stream and pick up the PAT/PMT/NIT etc as they repeat - this extends to the DVB-S/C monitoring equally cleanly. It seems that the DEC driver (and at a guess from the dev threads some other USB tuner drivers) do not support filtering only these packets onto the dvr output - and it doesn't appear to be a buffer filling issue with the DEC - they just don't turn up. (Though I'm still experimenting/trying to follow the driver code here :) ) At the moment the only way I can get pat/pmt/nit out of the 'untuned' dec is to make a request (as noted in much older threads on this box ) on the dmx using a dmx_sct_filter - and read the response on the dmx. I can't see anything in eg the fe info to allow any code to determine the pes_other filtering is not supported so I'd guess that writing generic monitor code to support the 'deficient' usb drivers would mean duplication of code and some sort of database flag - possibly in addition to the 'hardware decode' flag. It would obviously be far more preferable for the usb drivers to support the output transfer. still experimenting/learning ...... much more fun than the day job that keeps getting in the way :) _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
