Norwegian DVB-T channels wanted

[robinsmidsrod]

Hi everyone!

I tried using AutoBouquetsMaker on OpenATV 6.2 on a Dreambox DM7020HD, and ended up being blocked because there wasn't any option to find Norwegian channels distributed over DVB-T. I couldn't actually find any Norwegian providers at all in the configuration (not even for DVB-S2 or DVB-C).

What must be done to get those supported? Is there anything I can do to help things along?

[robinsmidsrod]

@Huevos I've added a PDF to the Dropbox folder with some test specification from RiksTV (NTV) about how to calculate best service selection. I found it somewhere deep in the pages of rikstv.no with some google-fu. From page 23 I think you'll find the juicy bits that'll help you to understand how they expect you to build the service list(s). I specifically talks about what is considered the "same" channel and you should determine which one to use. Hopefully it makes sense. I've added it here for reference.

riks-tv-test-specification-ver-2.0.pdf

[robinsmidsrod]

@Huevos I've gone through the generated Terrestrial bouquet more carefully now, and I've noticed that for all of the NRK TV and radio channels, I've only got one channel (NRK1 Østfold) which is from the mast with the stronger signal (TSID 0x1fe), while all the other channels in the bouquet are from the mast with the weaker signal (TSID 0x136). Is it possible that the channel duplicate selection algorithm is reversed, so it favors the weaker signal instead of the stronger one? Going through the generated bouquet and looking at the signal strength it looks like that to me.

[Huevos]

No it is not possible the duplication algorithm is reversed.

https://github.com/oe-alliance/oe-alliance-plugins/blob/master/TerrestrialScan/src/TerrestrialScan.py#L416

[Huevos]

So current logic is...

Step through frequencies...

For each active transport streams discovered.... Read signal level. Read SDT to get TSID + ONID (this can take up to 2 seconds per transport stream) Where there are duplicate TSID + ONID combinations save the stronger ones.

Once we have a list of transport streams, read the NIT of each trans`port stream to get the LCNs. Reading the NIT can take up to 30 seconds per transport stream.

To read the Network ID would require reading the NIT on every transport stream before saving.

[robinsmidsrod]

@Huevos As far as I can tell from the rikstv-test-specification file I uploaded earlier (page 23) it says the following:

Due to the asymmetrical nature of the terrestrial network and the fact that one unique service can be receive from different transmitters (and frequencies), independent of the regions, the following rules shall apply when building the service lists:

1. A unique service shall only be listed once. Observe that a unique service is defined by its _original_networkid and _serviceid in the terrestrial network (not _transport_streamid)
2. If the same unique service is found on several frequencies, the frequency with the best reception shall be used for that particular service. The IRD shall use the Signal Strength Indicator (SSI) and Signal Quality Indicator (SQI) as defined by Nordig Unified Specification [2] when determining the best frequency to use for a service. The Nordig Unified Specification [2] includes an appendix with implementation guidelines for selecting frequency in non-trivial situations.

Is this in line with what you described in the previous comment?

Also, is it possible that 2 seconds is not enough to get a stable signal level to store with the TSID/ONID from SDT? My STB is quite old, so it might actually take more than 2 seconds to get the correct signal level. Could this 2 second timeout be set by the user to work around slow hardware? I've noticed that zapping to a DVB-T channel can sometimes take up to 6 seconds on my hardware.

[Huevos]

First, lets be clear before we move on. ONID (Original Network ID) and Network ID are very different things. ONID for the current transponder can be retrieved from "SDT Actual", Network ID cannot and must be retrieved from the NIT.

The plugin says "Network ID" in the config page, but should say "Original Network ID". This needs changing.

The 2 seconds is is part of the DVB standard, which says the "SDT Actual" is to have a repeat interval of at least once every 2 seconds. This is not imposed by the plugin. Instead there is a 5 second timeout. https://github.com/oe-alliance/oe-alliance-plugins/blob/master/TerrestrialScan/src/TerrestrialScan.py#L377

To allow the signal strength to stabilize there is a 2 second sleep period imposed by the plugin. You can try changing this and see if your hardware responds favorably. https://github.com/oe-alliance/oe-alliance-plugins/blob/master/TerrestrialScan/src/TerrestrialScan.py#L410

In your quote, "point 1" is not compatible with the DVB standard. The DVB standard says that a SID is unique within a TSID and a TSID is unique within the ONID. Accord to your provider the unique combination is "ONID + SID". This plugin has no interest in SIDs because the DVB standard says the unique combination for a transport stream is "ONID + TSID".

I suspect the above is where we are failing. In all other systems so far encountered, if a unique transport stream is available on different masts the TSID will be identical (DVB standard). So we just need to test "ONID + TSID + Signal Quality" to identify unique transport streams. In fact if it is a repeater it must be identical because it is just resending the signal from the primary mast on a different frequency.

So if we are going to make any progress we need would need to completely rewrite the plugin contrary to DVB standards.

[robinsmidsrod]

@Huevos That "point 1" that I'm referencing is directly from the RiksTV/NTV specification for STBs that are approved to work with Norwegian DVB-T transmissions. Why am I not surprised that they're violating the DVB standard? It is so typical, in Norwegian technical standards, that they deviate from the international standards... sigh It isn't the first time I've heard about this happening.

I've run a new scan now with the sleep() changed from 2 to 5 seconds. It helped a lot! Now all of the NRK channels (TV and radio) in the bouquet are coming from the 0x1fe TSID, which is the one with the stronger signal. Is it possible to make the sleep() configurable, or should we just increase it to take into account slower hardware?

[robinsmidsrod]

@Huevos Also, the final gesture that would make this really nice is if the radio channels could be added to a Radio "Terrestrial" bouquet instead of the TV "Terrestrial" bouquet.

Looking at the information in the PSI->SDT it does seem like the TV channels use service_type 0x19 (25, H264/AVC HD digital television service) or service_type 0x16 (22, H264/AVC SD digital television service) and the radio channels use service_type 0xA (10, advanced codec digital radio sound service), so it seems doable to separate them into different bouquets.

[Huevos]

plugin.py.txt MakeBouquet.py.txt TerrestrialScan.py.txt

That adds the stabilization time to the user interface. I don't have time to code a radio bouquet at this time. Is there a collision between the TV and radio LCNs?

[robinsmidsrod]

@Huevos Thanks a bunch! I'll try them out a bit later today.

I was just wondering - since you don't have time to create a separate radio bouquet, would it be possible to fill in the DESCRIPTION line in the bouquet file with the channel name, as it would make it much easier when I copy the relevant lines into a new (manually created) radio bouquet file.

Also, when do you expect these changes you've made to TerrestrialScan to make it into OpenATV and/or the plugin there? Just wondering how long I'll need to hang on to these custom tweaks you've made.

[Huevos]

I can push these changes to github later today if I have a minute. That would get them into OpenATV at the next build.

Is there a collision between tv and radio LCNs?

[robinsmidsrod]

@Huevos As far as I can tell, there are no collisions between radio and TV LCNs. For Norwegian DVB-T signals the radio LCNs are all 2xx. There are no TV channels in that range. TV channels are all below 100 or 9xx.

I noticed you had some more typos in your files. In American English, it is written "Stabilization", or in UK English "Stablisation". With or without Z depending on language dialect. Not sure which language dialect is normally used, but you should continue using the same as the rest. There were also some other typos surrounding the same word in different forms. Most importantly, the variable name had a typo, which is unfortunate.

Great work all together!

Based on everything we've figured out so far, is an ABM provider still out of the question?

[Huevos]

TerrestrialScan reads every transport stream (UHF, 8 MHz steps). That means it doesn't matter if the frequency data is wrong in the NIT, because we can work it out from the tuned frequency.

ABM works by reading one single transport stream and harvests all the frequency data and other data to required to create the bouquets from that one single transport stream.

To make an ABM provider we would need to know the home transponder frequency for every mast in the country, and for the frequency data not to be broken how it is in the SI tables.

Also, we would need to add code to handle "channel_list_id" for DVB-T providers. And to know the correct "channel_list_id" of every mast in the country.

Given that it is unlikely we could get the provider to fix the frequency data in their SI tables and that there is no known public source for the home transponders or "channel_list_id" of every mast in the country, there is little hope of an ABM bouquet to be created for this provider.

[Huevos]

https://github.com/oe-alliance/oe-alliance-plugins/commit/2619b7cf0a094b294cbc6ea9b5de8eef29b2d0bf

[robinsmidsrod]

@Huevos Thank you for the updated plugin. I've installed it and run a scan with the new code.

I also noticed something new. I found a website with documents related to Norwegian frequency usage in the 470-790MHz bands:

https://frekvens.nkom.no/#/main

I'm not sure if it actually has a frequency chart, as there are a lot of documents in the list.

[Huevos]

You don't need a frequency chart. We know it is 8 MHz steps. What you need is a list of home transponders and channel_list_id 's, and that the tables are not broken. Right now NIT shows incorrect frequency data. ABM uses that data.

[robinsmidsrod]

@Huevos I gave you the link because it contains a lot of documentation, not necessarily only frequency information. The problem is that there is so much documentation that I don't know which document might contain the information we need.

[Huevos]

Closing this. TerrestrialScan can be used as a substitute for ABM in this situation.