[mythtv] Fwd: [linux-dvb] USB DVB-T tuners and MythTV
mythdev at penyball.cix.co.uk
Thu Oct 13 11:09:00 UTC 2005
> 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
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
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 :)
More information about the mythtv-dev