[mythtv] scanning and USB/Dec 2000 patches

[jd]

Daniel tidied up my approach to using the DEC 2000 - thanks!

so i've been looking at fixing the scanning (tuned full scan) and the 
attached 3 patches are my attempt - tested against svn 7882 for bt8xx, 
dec-ttusb and ivtv drivers using a UK PAL feed from the Moel Y Parc 
transmitter. (ivtv just to make sure I hadn't broken the analogue scan)

scanpatch1 fixes some oddities. 
a) the sql lookup for timeouts in ScanWizardScanner::scan() is broken so 
always defaults to a 40s channel timeout - the consequence of fixing this 
is that the channel timeout is likely to need changing on the capture card 
setup screen to allow scans which were working before to complete - I 
needed to set this at 8000+ for the DEC-2000 and 18000+ for the Avermedia 
771 card.
b) The ServiceHandler::GetPIDs was using 0x46/0xFB as the filter/mask - 
which ought to have given us both actual (0x40) and other (0x46) transport 
streams for SDT sections. It seems ttusb-dec hasn't implemented the mask 
so 0x40 packets were never appearing. Changing this to 0x42 shouldn't 
affect the scanning as implemented - as it either the single transport or 
all transports are scanned anyway.


scanpatch2 adds a further check to see if we really have got a PAT in
the DVBSignalMonitor::SupportsTSMonitoring check. This check looks for a 
section ID = 0 and relies o the fact in a DVB PAT the first PID should be 
0 / 0x10 which defines the NIT PID, to determine whether the returned 
packet holds a PAT after the 5 byte header.

In my case I was getting stream data on dvr0 which was not the PAT - (in 
fact the DEC never sends any SI tables on this output - and I waited a 
long time to check :) ) I suspect this does represent misbehaviour on the 
part of the driver (there should be no data?) but the additional check 
fixes this and shouldn't break anything else?  (The original version 
worked because I was checking PES_OTHER filtering on the demux port only.)


scanpatch3 addresses the failure of the scan to find all channels/scan all 
multiplexes.
 
In my case this was because the current transport scan only loads the 
centre frequency from the NIT transport descriptor into dtv_multiplex and 
ignores the 'Additional Frequencies'. On the Moel Y Parc transmitter this  
frequency is never used - it is always one of the additional frequencies 
that carries the stream. The only reason I was getting any channels at all 
is that two of these frequencies were the same as ones in the additional 
frequency lists for other transports.

I looked at getting SIScan::CheckNIT to work with the additional 
frequencies - but this falls foul of the fact that both the DEC and 
Avermedia cards are too helpful. eg If you ask to tune to 770000000 and 
the actual frequency is 770166000 it helpfully tunes you to the correct 
one but tells you it is tuned to the frequency you asked for :). The 
result is that multiple frequencies are seen as valid for the same 
transport so multiple mplexid's get created for what is really the same 
tuning and duplicate channels turn up.

What the patch does is load all network/transport/frequency values from 
the NIT into dtv_multiplex. (In my case I get 51 entries when actually 
only 6 are valid) To counter this ChannelUtil::GetBetterMplexID is 
extended to check that the frequency we asked to tune to is valid for the 
transportid and frequency we have saved in dtv_multiplex.

The consequence is that all (51) of the dtv_multiplex entries get scanned 
(upping the scan time, but scanpatch1 means the relative change is 
minimal), but only valid mplexid's are returned by 
ChannelUtil::GetBetterMplexID.  I specifically excluded the 
GetBetterMplexID fix from the calls in UpdateVCTinDB, UpdateSDTinDB, 
UpdatePATinDB as I have no way of testing these. I also couldn't decide 
whether this check should go before the first test of an exact match 
against the mplexid/networkid/transportid so put it afterwards :(

The 'bad' entries in dtv_multiplex could be cleaned out after a scan but 
its not obvious that they are doing any harm given that nothing is 
linked to them so I've left them there...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scanpatches2.bz2
Type: application/octet-stream
Size: 3842 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20051115/9fb0fc8e/scanpatches2.obj