139 replies to this topic

[Huevos]

No OE-A have not changed formats. By the way why has satellites.xml not been updated since June?

 

OE-A is updated weekly by automated process. Has been the same for the last 8 years.

Edited by Huevos, 8 August 2018 - 02:24.

[IanSav]

Hi WanWizard,

 

I wasn't even aware there are differences, did OE-A change to a different format, as we use the same as been used for the last 10+ years? Any other reason for incompatibility?

 

I have no clue about what this discussion is about, so please enlighten me.

 

The TuxBox files in the OpenPLi are a manually derived copy of the master data in the OE-Alliance repository.

 

The data in the OE-Alliance repository is programmatically generated on a regular basis by Huevos.  Those changes are then manually transferred to OpenPLi via a manual update, most recently done by Abu, on an irregular and far too infrequent basis.  For example, the OpenPLi terrestrial data was incorrect for Australia as the OpenPLi version of the file hadn't been updated in ages.

 

If OpenPLi would automatically draw the data direct from the OE-Alliance data it would always be in sync and up to date without any MANUAL data copying.  To make it easier for Littlesat to accept I just went through the OE-Alliance repository and adjusted all the XML files to be cleaned of trailing white space, leading SPACEs have been replaced with TABs, the self closing XML tags are all uniform with the more common and preferred leading SPACE and the line endings of all files have all been reset to UNIX friendly LFs.

 

Does this explain what is going on?

 

Regards,

Ian.

[Huevos]

No, cables.xml and terrestrial.xml are painstakingly maintained by AbuBaniaz. satellites.xml is the only file created automatically, same as PLi.  But for some reason PLi hasn't updated their file for 2 months and all the data is getting stale. e.g. missing multistream transponders on 5.0W.

[littlesat]

The satellites.xml should be an automatically Weekly sync from Lynsat. For the teristical.xml it is different as this data depends in the location and here we all depends on local data forwarded and added to the xml.
Actually cable.xml does not really help as cablescan en normal table scans replaces it. The same for teristical.xml when you eg love at a border and can receive two different countries..
The most optimal location to put these kind of data is to move it eg to e2openplugins or another ‘neutral’ location.
B.t.w. Someone needs to investigate why the satellite.xml was not upgraded...

Edited by littlesat, 8 August 2018 - 06:54.

[Persian Prince]

There isn't a generator script. The data is in a database. To create the file a query is sent to the database and the output converted to xml.

 

Ok so would you please give us something that we could use as a xml creator?

 

Where is the database? Do we need a php code or something to send query?

[IanSav]

Hi Littlesat and Persian Prince,
 

The satellites.xml should be an automatically Weekly sync from Lynsat. For the teristical.xml it is different as this data depends in the location and here we all depends on local data forwarded and added to the xml.
Actually cable.xml does not really help as cablescan en normal table scans replaces it. The same for teristical.xml when you eg love at a border and can receive two different countries..
The most optimal location to put these kind of data is to move it eg to e2openplugins or another ‘neutral’ location.
B.t.w. Someone needs to investigate why the satellite.xml was not upgraded...

 
I am relatively new here but I thought that the OE-Alliance repository *was* neutral ground.

 

As for the issues with your currently broken automated update system, aren't the current problems a good reason to switch over to using the common OE-Alliance source and not bother wasting limited resources fixing the broken system?

 

Ok so would you please give us something that we could use as a xml creator?

 
Where is the database? Do we need a php code or something to send query?

 

Does it really matter who fetches and processes the data.  As long as what is in the neutral repository is open to everyone and well maintained it could, and should, be used.  There is no need to start building a new and separate fetcher system.

 

If anyone has any manual updates then they should be submitted to the repository.  The pull requests should be reviewed for quality and, where practical, accuracy and then merged in for *everyone* to access.  I, for example, would be happy to keep the terrestrial data for Australia up to date by submitting pull requests whenever Prl rebuilds the Australian data.

 

I really do hope that any ill will and ego problems from the past can be left in the past and we all join to work together in making Enigma2 better than ever.

 

Regards,

Ian.

Edited by IanSav, 8 August 2018 - 08:16.

[Persian Prince]

@IanSav

 

I don't care where is the repo as you can see we use some OE-A repos in https://github.com/PLi-metas I just want to have another repo with different possibilities.

 

For example we can have a branch for my country with only what we can receive and also different branches for other countries and as we have users who build their own image we can add a new MACHINE feature like "xml-country" then they could have their own country-based image.

 

All I want to do is create more possibilities, still I don't get why there is a pressure here not to share the grabber ...

 

Regards,

Persian Prince

[IanSav]

Hi Persian Prince,

 

What you ask seems quite reasonable.  In Australia we only have DVB-T so we have custom TuxBox files as we don't use or need the cable or satellite services.  We only offer Australian terrestrial services as using the standard files clutters up our UI quite substantially.  Why not propose a structure for all the stake holders to review and see if we can progress an improved design.

 

Regards,

Ian.

[Persian Prince]

When I don't have the grabber I can't improve it I can't extend it, I need it to create a new repo with different configurations.

 

Please share PLi or Huevos version of this tool.

 

Regards,

Persian Prince

[IanSav]

Hi Persian Prince,

 

For the moment don't focus on the tools.  Let's look at the requirements and the structures required.  lET US First design the system then we can worry about building it.  For all we know the current tools could be able to support the new design.  If noT the author may simply make the changes so that it all just works.  That is the point and reward of co-operation you don't have to do everything yourself.

 

Regards,

Ian.

[WanWizard]

But for some reason PLi hasn't updated their file for 2 months and all the data is getting stale. e.g. missing multistream transponders on 5.0W.

 

All our buildservers have been down for over a month while we were looking for a new place to host them. They are now back online in the same datacenter that also hosts our online presence.

 

I've just checked it out, it did run again as scheduled, but it failed to update the repo, I'm having a look.

 

edit: problem fixed, repo updated.

[IanSav]

Hi WanWizard,

 

Is the OpenPLi code that automates the build open for review?

 

Regards,

Ian.

[WanWizard]

Is the OpenPLi code that automates the build open for review?

 

No, any particular reason you want access to it?

[Huevos]

Do you want a PR sent to bridge the gap while the fault is investigated?

[WanWizard]

Do you want a PR sent to bridge the gap while the fault is investigated?

 

No, thanks, already fixed, repo was updated 15 minutes ago.

[Huevos]

@PP, my system gets the data and stores it locally in MySQL. That way when someone requests a custom xml file it is just a case of sending the appropriate query to the database. To me it seems pointless everyone having a grabber and burdening the source website to retrieve the data over and over again.

[IanSav]

Hi WanWizard,

 

 

Is the OpenPLi code that automates the build open for review?

 

No, any particular reason you want access to it?

 

 

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.

Regards,

Ian.

Edited by IanSav, 8 August 2018 - 10:41.

[Pr2]

Hi,

I will give you my point-of-view on this.

 

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.

 

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.
 

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

 

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

 

Pr2

[Pr2]

• The second was because I would like to improve the XML code generated by adding a SPACE before the self closing tags.

If this is important for you I will create a ticket to have it include in the current xml service generator.

Edit:

Here it is, the issue is created:

https://devtools.ope....org/issues/235

Pr2

Edited by Pr2, 8 August 2018 - 10:50.

[WanWizard]

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 have a non-public repository which contains our complete build environment, so it can be cloned onto any linux machine and make it an OpenPLi buildserver. It also contains our artwork (with is not under GPL) and our image branding system. We have no plans to make that public. It is quite different from the standard bitbake "make image" system, and therefore not very useful for others.
 
I've added the space to the <transponder> tags, new update is online. Thanks.
 

Here it is, the issue is created:

And closed again.