20 replies to this topic

[Huevos]

Why are OpenPLi terrestrial.xml and cables.xml abandoned and not updated in 8 years? And why does terrestrial.xml have a cables entry?

[mimisiku]

Because they share the same frequency

120 Mhz through 862 Mhz
Only it's modulation type differs.
DVB-C is QAM64 through QAM256
DVB-T is COFDM
DVB-T2 is either H.264 MPEG4 or H.256/HEVC

[Huevos]

Because they share the same frequency

120 Mhz through 862 Mhz
Only it's modulation type differs.
DVB-C is QAM64 through QAM256
DVB-T is COFDM
DVB-T2 is either H.264 MPEG4 or H.256/HEVC

Yeah right? Why is cables in terrestrial.xml, not cables.xml? There is no such thing as a cables band plan. It is up to the provider to decide.

 

Try doing any sort of cable scan with that cables.xml. Not a hope. Only option in PLi is a DVB-C blindscan and just hope the manufacturer has provided a binary.

 

Also current terrestrial.xml means every frequency needs scanning. That means we have to scan and wait for the timeout on non existent transponders. We have to do a double scan so both DVB-T and T2 can be found. Proper method would be select your mast from the list and only scan the 5 or 6 active transport streams in your area.

 

Also having all those frequencies scanned in one go means double scanning same transponder in cases of transmitter overlap.

Edited by Huevos, 3 May 2017 - 21:44.

[WanWizard]

Afaik (but I'm not an expert in this matter) it is rather pointless to supply a cables.xml, since every cable provider needs different parameters. So if you provide an xml, you need to provide something with which a user can select his provider, in his specific location, which is a nightmare to create and maintain. So if you are a cable user, enter the "home" frequency, and do a scan. No blindscan needed.

[athoik]

What television has such option? All my TV are scanning all DVB-T channels, unless manual scan performed.

I think we are doing lot of baby-sitting in users

"Expert" Users can always add their custom file in /etc/enigma2 with the transponders available in their region.

"Normal" Users simply do full scan and get a coffee while scanning!

No idea about DVB-C though, maybe there the blindscan is a must without knowing the Cable parameters, but DVB-C blindscan is very easy to implement AFAIK.

Edited by athoik, 3 May 2017 - 21:47.

[littlesat]

I think having such xml for c and t is not something that is really required....

[Huevos]

What television has such option? All my TV are scanning all DVB-T channels, unless manual scan performed.

...

"Normal" Users simply do full scan and get a coffee while scanning!

E2 is not the same. E2 stores the TSID, ONID and SID and uses these to retrieve a channel. TVs obviously don't do that as they are able to store multiple copies of the same TSID/ONID combination. So if on channel 22 you have TSID 0x08C4 and then on channel 36 from another weaker mast the same TSID 0x08C4 it will over write the stronger version. Having a proper terrestrial.xml stops this happening.

Edited by Huevos, 3 May 2017 - 22:28.

[athoik]

So e2 needs to handle multiple same tsid/onid

[Huevos]

Afaik[...] if you are a cable user, enter the "home" frequency, and do a scan. No blindscan needed.

If only it were so easy. First thing you need to know is the network ID.

[Huevos]

So e2 needs to handle multiple same tsid/onid

No, because the transponder is identical so no point. I made a plugin that only scans the strong one... but that's a different story.

 

I just wondered why PLi never bothered to maintain these files, at least for major cities.

[WanWizard]

If only it were so easy. First thing you need to know is the network ID.

 

I know that.

 

These are published, and if you are a cable customer, it is more likely that you know or can find out what the local network ID is, then someone in other country. Let alone maintain it, and keep it up to date. 

 

So I still don't see what the problem is, and I think the alternative I think you suggest is worse. Unless you are volunteering now to become the global cable and terrestrial scan parameter maintainer?

[Abu Baniaz]

Thanks for merging the cables.xml and terrestrial.xml files.

 

A question, why was the cables.xml file not being included in builds? It is included in the makefile

 

https://github.com/O.../Makefile.am#L2

[WanWizard]

No idea, but as this is being addressed at the moment, I assume it is going to be fixed soon.

 

The new repo is already created (https://github.com/OpenPLi/tuxbox-xml) and the satellites.xml moved. Next step will be the other xml files.

[littlesat]

Why do we need cables.xml and terristical.xml in the first place? As far I can see it does not really help...

Edited by littlesat, 20 July 2017 - 06:54.

[WanWizard]

There's been conversations about it in other topics.

 

For terristrial it's needed to filter out frequencies from other base stations, if you have a good antenna on the root, you can receive multiple base stations. For cable similar reasons exist.

 

Besides, for most users it is easier just to select their home network. And don't forget, the reason we update the satellites.xml, is that scanning the list of defined transponders is a lot faster than a NIT scan. And the same applies (even more so) for terrestrial and cable.

[Erik Slagter]

I don't think there is a discussion needed whether some of these files are useful or required. There is no harm in including them in the first place, especially if they are maintained well.

 

Then, why are they're not updated. That has different reasons, one of them being resource problems causing the development and release builds not being produced as often as I'd like and also that the package was pinned in the rc builds and OpenPLi 4 (master/stable) will not get the update at all.

 

Last but not least I am in the process of moving these files into their own repository, allowing to make clean updates and PR's. Check here: https://github.com/OpenPLi/tuxbox-xml You can make your PR's to this repository now.

 

Last step is to adjust the recipe to the new situation and unpin this package in the rc builds. When all has completed successfully, you will have a tuxbox-common package that contains four *.xml files, no scart.conf file and it will have version 2.x.

Edited by Erik Slagter, 20 July 2017 - 11:35.

[nightflyer]

 

So e2 needs to handle multiple same tsid/onid

No, because the transponder is identical so no point. I made a plugin that only scans the strong one... but that's a different story.

 

I just wondered why PLi never bothered to maintain these files, at least for major cities.

 

Actually the assumption that the transponder is identical is wrong.

 

In Italy DVB-T, local RAI3 versions have the same service reference. So you can only get one using enigma2

 

More info here (in Italian):

http://www.vuplus-co...-diversi.14509/

[Huevos]

 

 

So e2 needs to handle multiple same tsid/onid

No, because the transponder is identical so no point. I made a plugin that only scans the strong one... but that's a different story.

 

I just wondered why PLi never bothered to maintain these files, at least for major cities.

 

Actually the assumption that the transponder is identical is wrong.

 

In Italy DVB-T, local RAI3 versions have the same service reference. So you can only get one using enigma2

 

More info here (in Italian):

http://www.vuplus-co...-diversi.14509/

 

Same in Holland. The local channel is inserted for each transmitter individually even though the TSID is the same. Anyway that is the way the broadcaster intends it to be. Any other system would break the LCNs they transmit.

[dhwz]

On latest Dream Images the namespace for DVB-T(2) is calculated including the frequency (freq is rounded +/- 1 MHz if I remember correctly, so namespace doesn't change on rescan if freq is a bit different), so duplicate transponders with identical ONID TSID can be stored and you can get all different regional services at the same time. Sure you get some duplicate services then also but you can always store the strongest one in your favourites.

[Huevos]

On latest Dream Images the namespace for DVB-T(2) is calculated including the frequency (freq is rounded +/- 1 MHz if I remember correctly, so namespace doesn't change on rescan if freq is a bit different), so duplicate transponders with identical ONID TSID can be stored and you can get all different regional services at the same time. Sure you get some duplicate services then also but you can always store the strongest one in your favourites.

Not sure what you mean. In OpenPLi it follows the values in terrestrial.xml or those entered by the user.

 

Anyway, no point continuing this thread as terrestrial.xml has been updated (thanks to all involved).