[mythtv] mythtv-setup - DVB channel scanning

[roger]

The code I just pushed to github.com/rogerjames99/mythtv channelscan 
branch is looking reasonable at least as as far as the tests in can do 
here in the UK.

It should handle the FrequencyList descriptor correctly but I cannot 
test that as they are no longer transmitted here.

Roger


On 27/02/17 12:41, roger wrote:
>
>
>
> On 27/02/17 10:22, Stuart Auchterlonie wrote:
>> On 23/02/17 14:34, roger wrote:
>>> I have been delving into DVB-T channel scanning in mythtv.
>>>
>>> When using "full scan (tuned)" and the transport port scans with "search
>>> new transports" with a DVB_T tuner we often see the scanner trying to
>>> tune transports that are not physically receivable by the hardware. I
>>> looked into this and found that the code was not honouring the
>>> other_frequency_flag in the TerrestrialDeliverySystemDescriptor
>>> contained in the per transport stream loop in the Network Information
>>> Table (NIT). This flag means that this particular transport stream is
>>> also available on frequencies other than the one specified in the
>>> TerrestrialDeliverySystemDescriptor itself. Information on these other
>>> frequencies information should be found a FrequencyListDescriptor for
>>> this transport. The ETSI EBU standards mandate that this flag must be
>>> set if a ChannelListDescriptor is present but not that a
>>> ChannelListDescriptor must be present if this flag is set, which seems a
>>> little weird.
>>>
>>> I plan to implement the following algorithm. I would appreciate comments
>>> on this.
>>>
>>> 1. If the other_frequency flag is present then (conditional on the usual
>>> stuff)  then go to step 2. otherwise use the centre frequency from the
>>> TerrestrialDeliverySystemDescriptor.
>>>
>>> 2. If the frequency I am actually tuned to is the same as the centre
>>> frequency from the TerrestrialDeliverySystemDescriptor then use it
>>> otherwise go to step 3.
>>>
>>> 3. If a FrequencyListDescriptor is present then go to step 4 otherwise
>>> use the centre frequency from the TerrestrialDeliverySystemDescriptor.
>>>
>>> 4. Add all the frequencies from the list to the list of new transports.
>>> Need to check if I can just do this blindly without ending up with
>>> duplicates when a new transports is tuned.
>>>
>>>
>>> I may have to extra work for this to work here in the UK. I have checked
>>> the streams coming from my local transmitter. They have the
>>> other_frequency_flag set but do not contain any
>>> FrequencyListDescriptors. I know that they used to. Because I have seen
>>> them in traces. Has anyone got any information on this?
>>>
>>>
>> Not information but some theories. Since the flag is meant to indicate
>> that the mux is available on other frequencies, but it doesn't include
>> the frequencies, then it's probably trying to signal that this mux could
>> be seen on multiple frequencies when doing a full scan.
>>
>> I'm guessing it is trying to give the receiver a heads up that it needs
>> to do some differentiation and decide on the "best" mux. Although why it
>> would need a flag to do that i dunno....
>>
>>
>> Regards
>> Stuart
>>
>>
>>
> Hi Stuart,
>
> I subsequently found a reference to this in an obscure old document I 
> have attached to this message.
>
> FrequencyList descriptors were removed from  the UK radiated SI in 2007.
>
> So now here in the UK the flag tells us that the freqeuncy in the TDS 
> descriptor is probably wrong if you are tuned to a local relay 
> transmitter. But now you have no hints to what the correct one is. So 
> now you probably have to use a geographical location and a database. 
> However some cheeky blighter has managed to get a patent on that 
> process, https://www.google.com/patents/WO2011161582A1?cl=en. 
> <https://www.google.com/patents/WO2011161582A1?cl=en>
>
> Roger
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-dev
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-dev/attachments/20170227/15f49d08/attachment.html>