139 replies to this topic

[Huevos]

Hi Persian Prince,
 
I have now had a chance to load the T3 image on my receiver.
 
The good news:

• The build appears to work fine.

The bad news:

• The service scan is wrong for Australia.  We have 7MHz bandwidth for each channel in both VHF and UHF.  One of the channels in the UHF band can't be found due to the 8MHz scan parameter.
• The broadcast channel list is out of date and incorrect.  Australia no longer uses UHF 52 - 69 for DVB-T.  Those frequencies have now been sold to other uses.  Scanning for Melbourne Australia scanned a lot of channels that are not used.
• The Australian picons are old and out of date.
• There are no online updates for the build.
• The are few plugins available.
• There is no option for the Beyonwiz remote control image / layouts.
• I have no SMB / Samba access to I can't access the image to install my test code.

There is probably lots more to report but there is not enough working for me to productively use this build.
 
I appreciate the efforts but this image is not really ready for use by a developer in Australia.
 
Regards,
Ian.

You need to set your tuner up properly. Tuning steps are correct for Australia. Just select the correct provider in the tuner setup. If frequency data is stale send a PR.

Edited by Huevos, 6 August 2018 - 09:27.

[IanSav]

Hi Huevos,

 

You need to set your tuner up properly. Tuning steps are correct for Australia. Just select the correct provider in the tuner setup. If frequency data is stale send a PR.

 

I built the box from scratch using the image provided.  I selected the country as Australia, the timezone as Melbourne.  I set the tuner to be DVB-T2 (DVB-T is not displayed as an option though a DVB-T scan was performed).  I then selected a "Melbourne" scan.  The scan was mostly correct but is got it wrong in the UHF part of the scan.  What else should I have done to get a correct scan for Melbourne Australia?

 

Regards,

Ian.

Edited by IanSav, 6 August 2018 - 09:31.

[Pr2]

Hi Huevos,

 

You need to set your tuner up properly. Tuning steps are correct for Australia. Just select the correct provider in the tuner setup. If frequency data is stale send a PR.

 

I built the box from scratch using the image provided.  I selected the country as Australia, the timezone as Melbourne.  I set the tuner to be DVB-T2 (DVB-T is not displayed as an option though a DVB-T scan was performed).  I then selected a "Melbourne" scan.  The scan was mostly correct but is got it wrong in the UHF part of the scan.  What else should I have done to get a correct scan for Melbourne Australia?

 

Regards,

Ian.

 

Hi,

 

If you know the frequencies and all other parameters used in Melbourne then you can always perform a manual scan by specifying all the paramaters.

In the manual scan screen use the left/right arrows on the line to change the possible options, and one of them will be "defined by user" and it will show you all the option to be filled in.

 

Pr2

[IanSav]

Hi Pr2,

 

My point is that the OpenPLi defaults are broken.

 

I am now working with Huevos to update the OE-Alliance terrestrial.xml defaults for Australia.

 

Regards,

Ian.

[Huevos]

Hi Pr2,

 

My point is that the OpenPLi defaults are broken.

 

I am now working with Huevos to update the OE-Alliance terrestrial.xml defaults for Australia.

 

Regards,

Ian.

And when correct these changes can be pushed to PLi.

[Pr2]

Hi,

 

I was answering on your question on how to "work-around" the problem, and I was also thinking to point you to the terrestrial.xml to correct it. 

 

Pr2

[IanSav]

Hi,

 

I have given the updated channel information to Huevos.  He has updated the scanning data for Australia and added the data for New Zealand to the Oe-Alliance code.  Hopefully it will get to OpenPLi soon.

 

By the way, I tested the data on my test version of OpenPLi and all the channels and services scanned quickly and correctly!

 

Regards,

Ian.

Edited by IanSav, 6 August 2018 - 16:23.

[WanWizard]

Our xml's are here, PR's are welcome.

[Abu Baniaz]

Our xml's are here, PR's are welcome.

I have submitted a pull request to take in the changes to the OEA version since last merge.

 

I have left the last one to avoid risk of rejection.

Edited by Abu Baniaz, 7 August 2018 - 02:26.

[IanSav]

Hi WanWizard,

 

Our xml's are here, PR's are welcome.

 

Why don't you also draw your tuner information from the OE-Alliance repository?

 

If all the teams used and contributed to the same source repository then the data would be more consistent and more up to date.  It is a pain to have to submit the same data to multiple repositories.  We really need to start helping each other.

 

Regards,

Ian.

[littlesat]

Why don't you also draw your tuner information from the OE-Alliance repository

maybe to avoid white spaces (at least to have it under control) and avoid extra conplicarions (see eg unicable.xml)

Edited by littlesat, 7 August 2018 - 06:51.

[IanSav]

Hi Littlesat,

 

 

Why don't you also draw your tuner information from the OE-Alliance repository

maybe to avoid white spaces (at least to have it under control) and avoid extra conplicarions (see eg unicable.xml)

 

 

What are the issues in the OE-Alliance version?  I just ran a diff and they are very close already.  Perhaps your concerns can be considered and the OE-Alliance version updated so that you can simply use the same version of these files.

 

All this duplication is a waste of time and effort for our limited programming resources.

 

Regards,

Ian.

Edited by IanSav, 7 August 2018 - 06:57.

[littlesat]

I fully agree... but you don’t know that actually vix, openatv are based on a fork of openpli... and openpli is a fork of an accident dream multimedia which does not exist anymore at least for enigma2 in open. So it is deeper ‘issue’ as you think. At eg. Openatv a log of commits are accepted as we are a bit tighter what we accept. So using a fork as new master with a risk it can break sonething when someone thinks add a good intended feature over there is a bit twitchy... Then PP merge action is a better approach... just merge commit is...

For e.g. Unicable.xml we simplified the code and xml and avoided duplicated keys and values that had the same meaning.

Edited by littlesat, 7 August 2018 - 07:16.

[IanSav]

Hi Littlesat,

 

I am in the process of cleaning up the white space and XML formats of the OE-Alliance files.  Hopefully that will make using those files more acceptable for OpenPLi.  In the future, if you see a problem in the OE-Alliance version then simply fix the problem and raise a pull request so that all the images can benefit from the correction.

 

Regards,

Ian.

[IanSav]

Hi Littlesat,
 
I have raised Pull Request #64 to clean up the white space issues in all the TuxBox files in the OE-Alliance repository.
 
I have also edited the README.md file to ask all contributors to those files to please keep the files clean and correct.
 
Regards,
Ian.

Edited by IanSav, 7 August 2018 - 08:46.

[WanWizard]

I have submitted a pull request to take in the changes to the OEA version since last merge.

 

I have left the last one to avoid risk of rejection.

 

Merged.

[IanSav]

Hi Littlesat and WanWizard,

 

The pull request to clean up the white space in the OE-Alliance files have been merged.  Is there anything else that stops OpenPLi from referencing, contributing to and using this shared resource?

 

Regards,

Ian.

[Abu Baniaz]

There are now differences between the PLI and OE-A version because of your changes. I will not be spending my time syncing them again until someone else sorts out the differences. I hope your changes do not conflict with the script that Huevos and PLI uses to obtain the data form Lyngsat.

[IanSav]

Hi Abu,

 

If there are issues then they can be fixed.  The changes I made were specifically to address Littlesat's complaints and issues with the OE-Alliance version of the files.  All the files now have UNIX line endings,  All leading SPACEs have been replaced with TABs.  All XML tags now have the more conventional SPACE before the self closing tag.

 

I have had a chat to Huevos and I am hopeful that the line ending correction should not be an issue, even for people working on Windows.  The important thing to consider is that on Windows a UNIX line ending aware editor must be used.  Notepad is NOT a compatible or appropriate editor.  Use something like Notepad++.  For most people who download the files from the repository the line endings will automatically be converted to be appropriate for the platform where the files were placed.  When the files are uploaded then the UNIX line endings should be restored.

 

If Littlesat or WanWizard are interested then I would be happy to manually edit the OpenPLi versions of the files to make the same corrections.  That should then reveal the few actual differences between the files.  Those differences could easily then be uploaded to the OE-Alliance copy and then OpenPLi can simply access the latest version of the files directly from the OE-Alliance repository.  Less work and more accurate files for everyone!

 

Regards,

Ian.

[Huevos]

@IanSav

 

Your changes just make it more difficult for us. (the people who are supplying the changes) to keep the files in sync. I hope that PLi do not accept this change.

Edited by Huevos, 7 August 2018 - 12:33.