<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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.</p>
<p>It should handle the FrequencyList descriptor correctly but I
cannot test that as they are no longer transmitted here.<br>
</p>
<p>Roger<br>
</p>
<br>
<div class="moz-cite-prefix">On 27/02/17 12:41, roger wrote:<br>
</div>
<blockquote
cite="mid:6db14a46-761c-6b57-2433-9a1037b43684@beardandsandals.co.uk"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 27/02/17 10:22, Stuart
Auchterlonie wrote:<br>
</div>
<blockquote
cite="mid:7bd0fe65-cc41-db0a-591b-73675de50c5b@squashedfrog.net"
type="cite">
<pre wrap="">On 23/02/17 14:34, roger wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
Hi Stuart,<br>
<br>
I subsequently found a reference to this in an obscure old
document I have attached to this message.<br>
<br>
FrequencyList descriptors were removed from the UK radiated SI in
2007.<br>
<br>
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, <a moz-do-not-send="true"
href="https://www.google.com/patents/WO2011161582A1?cl=en">https://www.google.com/patents/WO2011161582A1?cl=en.</a><br>
<br>
Roger<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mythtv-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mythtv.org/mailman/listinfo/mythtv-dev">http://lists.mythtv.org/mailman/listinfo/mythtv-dev</a>
<a class="moz-txt-link-freetext" href="http://wiki.mythtv.org/Mailing_List_etiquette">http://wiki.mythtv.org/Mailing_List_etiquette</a>
MythTV Forums: <a class="moz-txt-link-freetext" href="https://forum.mythtv.org">https://forum.mythtv.org</a></pre>
</blockquote>
<br>
</body>
</html>