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...
scanpatches2.bz2
Description: Binary data
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
