139 replies to this topic

[Huevos]

Bah. Diff checking these files is impossible. Why doesn't the PLi file run in the correct order?

 

OE-A file runs :

from -1771 to 1801 sequentially.

 

OpenPLi version runs:

from 19 through to 1801 and then -08 through to -1771.

And goodness knows why it has leading zeros attached to "-08".

 

Can this be fixed?

[Huevos]

Also, where is "t2mi_plp_id" used in enigma2?

[IanSav]

Hi Pr2,
 

Having a central repository for the .xml files I agree with this approach especially for DVB-T and DVB-C, because I already maintain myself such file (the Belgian cable Voo are mine) so I know which amount of work it is. For DVB-S there are already many websites that provide the information and if image maker decide to use there own grabber I think that we should respect this.

 
It seems we are arriving at violent agreement on sharing the TuxBox data! 
 

Moreover an error in the .xml file won't prevent the building of the image but it has an impact on the configuration of the tuner.
If the satellite.xml il missing or corrupted the tuner configuration are lost!  Because satellite.xml is used to mention the satellite name in the configuration. On a simple installation like mine (a DiseqC with 4 entry this is not a problem to reconfigure it but on more complex installation this can be a problem).
 
So it is important to have a tool to run on the .xml file to validate them, to be sure that they are not broken. A kind of .xml validator that can be run before building the image and if it fails re-use the last valid .xml file.

 
It is important for everyone to be able to trust the shared resource.  It should be up to the curator / co-ordinator to test and ensure the quality of the data.  Should an error be detected, by anyone, it should be the highest priority that the issue be addressed as it may affect many images and builds.
 

Making image country specific is not really useful I think. Just to have smaller .xml file and perhaps suppress some languages...

 
In Australia it was a design / implementation decision that all non Australian features be hidden from users.  Many of you here would not really recognise the Beyonwiz image as Enigma2!
 

IanSav says that in Australia only DVB-T is used so no need for DVB-S or DVB-C but this doesn't seems to be true. What about VAST satellite services?
 
https://www.myvast.com.au/
 
https://www.acma.gov...tellite-TV-VAST

There are private satellite services that use privately supplied and encrypted receiver boxes.  Enigma2 would NOT be welcomed.  ALL Australian receivers are DVB-T only.

 

Regards,

Ian.

[IanSav]

Hi WanWizard,

 

Thanks for the formatting improvement. 

 

Regards,

Ian.

[Huevos]

Where is "t2mi_plp_id" used in enigma2?

[Huevos]

 

There were two aspects to the request.

• The first was trivial and was to see if the reciprocal request for access to the build code was accepted by OpenPLi.   
• The second was because I would like to improve the XML code generated by adding a SPACE before the self closing tags.

 
We [...]

 

I've added the space to the <transponder> tags, new update is online. Thanks.

 

 

Where? I can't see the commit.

[IanSav]

Hi Huevos,

 

Where? I can't see the commit.

 

Pr2 posted the link: https://devtools.ope....org/issues/235

 

The actual source code is not public as mentioned by WanWizard above.

 

Regards,

Ian.

Edited by IanSav, 8 August 2018 - 14:55.

[Huevos]

Ok. So no commit and a link to a closed forum. I give up.

[IanSav]

Hi,

 

Everyone appears to want to have their own private programs.  So be it.  Does it really matter how the data gets into the shared repository?  As long as the data is accurate and timely.  That is what really matters.

 

Perhaps the two current data generators should produce a build of data and the results posted so that a comparison of the accuracy, quality and presentation of the data can be made.  The generator that produces the best data can be used.  Any enhancement requests then become a responsibility of the provider.  All requests for changes must be appropriately considered and if acceptable promptly developed and activated.

 

Thoughts?

 

Regards,

Ian.

[WanWizard]

Bah. Diff checking these files is impossible. Why doesn't the PLi file run in the correct order?

 

The only file we generate is satellites.xml, and it is gabbed in whatever order Lyngsat lists them. Since we were first, why doesn't OE-A use the correct order?

[IanSav]

Hi WanWizard,

 

Let's play nice.  Please can't we all work towards a productive solution?

 

Regards,

Ian.

Edited by IanSav, 8 August 2018 - 15:27.

[WanWizard]

Ok. So no commit and a link to a closed forum. I give up.

 

I wonder why you even started. This was about terrestrial.xml, which we don't maintain at all, like the cable.xml.

[WanWizard]

Please can't we all work towards a productive solution?

 

Let's start by defining the problem then? Because I don't see it.

 

There is a satellite.xml which we generate for OpenPLi images, which we're perfectly happy with, and which we're not going to change. Because there is no reason to. And then there is the terrestrial.xml and cable.xml which we don't maintain at all, and see no problem syncing this one with the OE-A one, which already happens by Abu every now and then... 

[Pr2]

Ok. So no commit and a link to a closed forum. I give up.

 

I don't think that this is a "closed" ticketing system, I think that you connect to it with your OpenPLi forum credentials. But there is no Single-Sign-On.

But you need write access to create new issues.

[IanSav]

Hi WanWizard,

 

The problem is, as I see it, that every image seems to be creating its own version of the same data.  For whatever reasons these various versions are not always up to date.  The idea is that we all constantly contribute and update data to a single, curated, repository.  This will allow all images to fetch the data from that one repository where the data is constantly updated and refined such that all images can get an up to date and consistent version of the data.  The more people contributing to the one repository the faster the data will be updated and the quicker problems can be identified and fixed.

 

For example, this all started when I installed a very recently built OpenPLi but the terrestrial data was SO out of date I could not perform a successful service scan.  The actual services in Australia have been stable for years!  The OpenViX data was not current but it has been good enough to work for the couple of years that I have been working with OpenViX.

 

I am happy to give everyone constantly updated Australian data but I am sick of doing things multiple times, once for each image I support.  The data in question is common to all builds so why can't it be managed communally?  If we all commit the partial updates for which we have good sources into the one place then EVERYONE can share the improved quality data.  All the various image developers can then be freed to do more productive development on their own images.

 

Does this reply address your question?

 

Regards,

Ian.

[Pr2]

Hello,

 

I think that we mix up several problems:

 

- Satellite

 

The satellite.xml is not manually maintain by any image providers they all seems to use personal method to grab data from well-know satellite website maintaining the list of TP for each satellite (it seems that they all used lyngsat).  So there is no issue here, there was a problem with OpenPLi that stop grabbing since 2 month but this is now fixed and the cosmetic space has been added.

 

However Huevos point out that OpenPLi doesn't support yet the "t2mi_plp_id" tag in there satellite.xml, I guess that it is perhaps because none of the STB supported by OpenPLi support it.  So another specific thread must be created to discuss this very specific issue.

 

- Terrestrial and Cable

 

There is no automated process to generate them, so they are manually maintained.  The one used by OpenPLI are the same as the one used by OE-Alliance, the sync is done by Abu.

 

But what this highlight is that it perhaps miss on the Internet a website where people maintain the DVB-T and DVB-C frequencies used by different countries/providers. A kind of lyngsat for DVB-T and DVB-C.  

 

But for DVB-C (Cable) there is the cable scan plugin that is working fine, so the need to have a cable.xml is less important, but people need to know the parameter to set in cable scan.

 

Editing manually the terrestrial.xml (or cable.xml) is error prone, so I am in favour of a dedicated website that will easily allow people from all over the world to submit changes. So image makers can, like they do for satellite, generate the .xml files from it.

 

And I guess that people using ATSC have the same needs. 

 

Pr2

[Huevos]

 

Bah. Diff checking these files is impossible. Why doesn't the PLi file run in the correct order?

 

The only file we generate is satellites.xml, and it is gabbed in whatever order Lyngsat lists them. Since we were first, why doesn't OE-A use the correct order?

 

Lyngsat doesn't list them like that? Anyway why would you want to retain the sort order from Lyngsat?

 

-5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5 (OE-A)

0, 1, 2, 3, 4, 5, -1, -2, -3, -4, -5 (PLi)

 

Which seems the sensible order?

[IanSav]

Hi Pr2,

 

I wouldn't be trusting Lyngsat for information either.  After the comment about the availability of satellite services for Australia I had a look at their website and some of the information about copies of the Australian FTA to satellite have old details!  For example, "ABC 2 ..." is now known as "ABC Comedy/Kids ...", the NITV logo is old and has been replaced and "SBS Viceland ..." is actually "SBS VICELAND ..." and the logo used is wrong.

 

Regards,

Ian.

Edited by IanSav, 8 August 2018 - 17:51.

[Huevos]

Hi Pr2,

 

I wouldn't be trusting Lyngsat for information either.  After the comment about the availability of satellite services for Australia I had a look at their website and some of the information about copies of the Australian FTA to satellite have old details!  For example, "ABC 2 ..." is now known as "ABC Comedy/Kids ...", the NITV logo is old and has been replaced and "SBS Viceland ..." is actually "SBS VICELAND ..." and the logo used is wrong.

 

Regards,

Ian.

Send an update to the site then. That's how it works.

Edited by Huevos, 8 August 2018 - 17:53.

[IanSav]

Hi,

 

 

-5, -4, -3, -2, -1, 0, 1, 2, 3, 4, 5 (OE-A)

0, 1, 2, 3, 4, 5, -1, -2, -3, -4, -5 (PLi)

 

Which seems the sensible order?

 

It looks like someone used an alphabetic rather than numeric sort. 

 

Regards,

Ian.