ABM (Terrestrial): Frequency Finder. Birdman's thread

[abu baniaz]

It scans ALL the European band. Stores the valid and receivable ones at that point in time. Whether it has changed or not.

And once again, mixing up ABM and Enigma2 scanning.

[Huevos]

So it isn't actually what I suggested, as I suggest remembering all available muxes and scanning just those. As had been noted (in this thread?) the main DVB-T muxes don't refer to any DVB-T2 ones.

Gordon, if you are not happy with the content of the SI tables you need to complain to the relevant competent body. As far as "DVB frequency finder" is concerned it does store all the frequencies including T2 muxes.

[EMJB]

This is not correct. The main mast only contains data related to the main mast. Repeaters only contain data about the main mast. For this reason trying to do a network search of a repeater is pointless. And any network scan done in the UK of the main mast will not return unknown T2 muxes.

The only time that would happen is if you were scanning a repeater.

Use the correct region in your tuner config so only the correct muxes area scanned. If you want to scan in 2 identical muxes turn on namespace subnet for DVB-T. If you only want to scan the strong version of any particular mux use the TerrestrialScan plugin.

Thanks for your corrections. However they confirm my opinion that the network scan is not only useless, but dangerous in at least some circumstances (i.e. when scanning for a repeater). It therefore seems very strange that it is the default setting, and that the "terrestrial.xml" file calls for a network scan in all UK cases (though from earlier discussions I understand this is ignored!).

With regards to your last point, it still seems to me that this would be much easier for you and for the user if you adopted the Topfield community approach of storing two sets of mux frequencies for transmitters that are about to be subjected to frequency shuffles.

EMJB

[birdman]

And once again, mixing up ABM and Enigma2 scanning.

Scanning is scanning. Why should there be more than one way to produce a lamedb file?

[birdman]

With regards to your last point, it still seems to me that this would be much easier for you and for the user if you adopted the Topfield community approach of storing two sets of mux frequencies for transmitters that are about to be subjected to frequency shuffles.

I don't recall the Topfield storing any transmitter frequency tables. As I recall it just remembered the currently used ones. Could well be wrong, though. It's several years since mine was running.

Having the old and new frequencies in the file at the same time is an interesting suggestion. All changes are known well in advance (they're all known now for the 700MHz clearance) so it should be possible to produce this. The only issue then would be is someone were to pick up a weak signal on one of the frequencies not currently in use at their local transmitter, but I'd hope this would be unlikely.

[Huevos]

Scanning is scanning. Why should there be more than one way to produce a lamedb file?

Because there is more than one way to store the data in the SI tables. "system scan" is only compatible with the generic method.

[Huevos]

The only issue then would be is someone were to pick up a weak signal on one of the frequencies not currently in use at their local transmitter, but I'd hope this would be unlikely.

That is not what he meant. He meant have 2 regions for each area in terrestrial.xml.

[birdman]

That is not what he meant. He meant have 2 regions for each area in terrestrial.xml.

Possibly, but adding old and new frequencies for each transmitter until after they've switched might work.

[birdman]

Because there is more than one way to store the data in the SI tables. "system scan" is only compatible with the generic method.

Which doesn't answer the question of why there should be more than one way to produce a lamedb file.

[abu baniaz]

Can you please clearly, concisely and succintly state what you want to achieve/query in this thread please.

ABM does not scan, it reads. Nobody is forced to use ABM. Those who want to can add any corrections/extra required details that they need. The new feature makes it easier for us and users. Instead of having to ask for lamedb files, asking them to scan individual frequencies, clear before scanning, run scripts to delete channels etc. They can run the new feature. They will have a ready to use ABM provider file without waiting for anyone. When they upload the file, we can add to ABM and they won't have to run the feature again.

[EMJB]

I don't recall the Topfield storing any transmitter frequency tables. As I recall it just remembered the currently used ones. Could well be wrong, though. It's several years since mine was running.

I used the wording "Topfield community" to distinguish between the original Topfield firmware and various community-added features facilities. The "FastScanGui" TAP has the tables built in, The Channel Organiser TAP has essentially the same information as a separate file akin to "terrestrial.xml", and the TopManager PC application has the tables built in (I think). The user selects either the old or the new set according to the date in the name and the current date, so there is no problem in picking up signals on one of the frequencies not yet, or no longer, in use.

EMJB

[Huevos]

With the TerrestrialScan plugin there is an option to create a terrestrial.xml file specific to the current location. Not need for any prior info coming from an outside source. It does an exhaustive scan and saves the result, just the same as "DVB-T frequency finder" does for ABM. Just select the option and run the plugin. Here is what it produces for Crystal Palace.

<?xml version="1.0" encoding="UTF-8"?>
<!-- File created on Monday, 06 of August 2018, 08:15:43 with the TerrestrialScan plugin -->
<locations>
	<terrestrial name="My local region (Europe DVB-T/T2)" flags="5">
		<transponder centre_frequency="482000000" system="0" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="490000000" system="0" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="506000000" system="0" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="514000000" system="0" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="529833000" system="0" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="546000000" system="1" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="586000000" system="0" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="746000000" system="1" bandwidth="0" constellation="3"/>
		<transponder centre_frequency="754000000" system="1" bandwidth="0" constellation="3"/>
	</terrestrial>
</locations>

[birdman]

Can you please clearly, concisely and succintly state what you want to achieve/query in this thread please.

Remove the requirement to have a transmitter configuration file, which needs to be kept up to date.

ABM does not scan, it reads. Nobody is forced to use ABM.

This is nothing to do with creating bouquets - it just about creating a lamedb file.

[birdman]

With the TerrestrialScan plugin there is an option to create a terrestrial.xml file specific to the current location. Not need for any prior info coming from an outside source. It does an exhaustive scan and saves the result, just the same as "DVB-T frequency finder" does for ABM. Just select the option and run the plugin. Here is what it produces for Crystal Palace.

That sounds like what I want.
I'm suppose I'm really asking why this isn't the default, and indeed only, method available.

[Huevos]

That sounds like what I want.
I'm suppose I'm really asking why this isn't the default, and indeed only, method available.

Well you have managed to take this thread completely off topic because it was about auto-creation of ABM provider files.

And of course exhaustive scans are not going to be the only way because they are way too slow.