[mythtv] scanning and USB/Dec 2000 patches

[jd]

> Don't most of these "fixes" fall into the fix it in the driver
> category ? 

Yes, thats why I'd separated them as discrete patches - and didn't put 
them on trac :)

The dec driver is definitely broken in that it should not be putting 
anything on dvr0  except SDT's when the filter is set - instead it puts 
the tuned stream and ignores any mask - but there are people who have this 
piece of kit and would like it to work - so I was making the patches 
'available'.   This fault is related to the inability of the device (ie 
not the driver) to filter PES_OTHER packets. There appears to be no device 
command that will allow these packets to be retrieved in any way other 
than by a direct request. Which is how the driver implements the 
sct_filter. So the 'stream on dvr0' behaviour is understandable but still 
wrong - fixing the driver won't make the filter work because the device 
won't support the filter.


The behaviour where the tuner is 'helpful' is more problematic - I suspect 
thats much more generic as both cards I have exhibit the same behaviour. 
Asking to get a tune lock with a frequency that is within one or two 
offsets may be design behaviour?  (The dec will lock +/- two step sizes, 
the avermedia locks within +/- 3)

I would expect FE_GET_FRONTEND/the drivers to be reporting the last 
frequency that was requested rather than going to the trouble of asking 
the tuner exactly what was locked - always presuming the tuning circuit is 
able to report that? Certainly thats what seems to be happening on these 
cards - which means FE_GET_FRONTEND is in the chocolate teapot category 
for what we want. (CheckNIT)

If this is generic behaviour then there ain't no way to get hold of the 
'actual' frequencies to tune/scan just by trying to tune  - these patches 
are one way - I'd hope there might be another but I don't know enough 
about the devices/drivers out there. 

The current myth scan based on the transport 'centre frequencies' means 
that there will always be channels missed except where the Other_Frequency 
flag is clear. This will need to be addressed at some point if scanning is 
to work. (This may be Steve's (adeffs at gmail) problem?)  Loading all the 
frequencies then checking the SDT transportid/frequency is one way of 
fixing this. (Putting the check into CheckNIT would be possible but then 
you're just duplicating a scan & packet parsing )

> Also I believe those additional transports will foul up the scan 
existing transports mode
It does in that there are more transports to choose from - but with the 
patches its not an issue - there are 3 situations to handle:

a) A frequency that locks because it is 'correct'
b) A frequency that locks because the tuner is helpful
c) A frequency that doesn't lock

In the a) case the requested frequency and the transportid in the Service 
table will match a valid transport/frequency combination in the NIT 
(dtv_multiplex) and all the channels will be loaded. 

In the b) case these will not match and the GetBetterMplex will return an 
mplex value that is valid for the SDT and a frequency within 2 offsets of 
the tuned frequency. Channels will be loaded if they haven't already been 
met.

In the c) case there won't be a signal lock and the signal timeout kicks 
in ( or if there is because the driver is broken the channel_timeout kicks 
in)

cheers
jim