[mythtv] Fwd: [linux-dvb] USB DVB-T tuners and MythTV

[Jim]

...
> 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 :)