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