139 replies to this topic

[IanSav]

Hi Huevos,

 

 

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

 

I am not a satellite user so I can't verify what is going on.  Such changes are better suited to someone who can verify the accuracy of the proposed corrections.

 

(Most of the data is already available in the Australian picon package maintained by Prl.)

 

Regards,

Ian.

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

[Huevos]

Hi Huevos,

 

 

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

 

I am not a satellite user so I can't verify what is going on.  Such changes are better suited to someone who can verify the accuracy of the proposed corrections.

 

(Most of the data is already available in the Australian picon package maintained by Prl.)

 

Regards,

Ian.

The thing is you are complaining about the services and picons. But that is not relevant. Only the transponder parameters are of any interest to us. Anyway no point complain that the data is wrong but not correcting it.

Edited by Huevos, 8 August 2018 - 18:20.

[IanSav]

Hi Huevos,

 

The thing is you are complaining about the services and picons. But that is not relevant. Only the transponder parameters are of any interest to us. Anyway no point complain that the data is wrong but not correcting it.

 

What a rude and unhelpful comment.

 

I was not complaining about the data as I don't and can't use it.  I simply pointed out that the reference source for all the satellite data may not always authoritative or correct.

 

I also pointed out that it was inappropriate for me to correct the data as I can't receive or test the signal so I can't verify what is actually going on.  As a believer of providing accurate and reliable information it would be contradictory of my standards to provide information that I cant verify or substantiate.

 

If you are offering to supply and fit all the satellite equipment required to receive these signals then I would be happy to provide verified corrections.

 

Regards,

Ian.

[Huevos]

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.

No idea. Here is how I do it...

SELECT DISTINCT 
  transponders.orb_pos, satellites.sat_name, transponders.frequency, transponders.symbol_rate, transponders.polarisation, transponders.fec_inner, transponders.DVB_system, transponders.modulation, transponders.is_id, transponders.pls_code, transponders.pls_mode, transponders.S2X 
 FROM 
  transponders, satellites 
 WHERE 
   (transponders.DVB_system = 0 OR (transponders.DVB_system = 1 AND (transponders.fec_inner > 0 OR transponders.S2X = 1)))
  AND 
   transponders.feed = 0
  AND 
   transponders.orb_pos = satellites.orb_pos 
ORDER BY 
  transponders.orb_pos, transponders.frequency, transponders.polarisation %2, transponders.symbol_rate, transponders.fec_inner, transponders.DVB_system, transponders.modulation, transponders.is_id, transponders.pls_code, transponders.pls_mode 

[Huevos]

Hi Huevos,

 

The thing is you are complaining about the services and picons. But that is not relevant. Only the transponder parameters are of any interest to us. Anyway no point complain that the data is wrong but not correcting it.

 

What a rude and unhelpful comment.

 

I was not complaining about the data as I don't and can't use it.  I simply pointed out that the reference source for all the satellite data may not always authoritative or correct.

 

I also pointed out that it was inappropriate for me to correct the data as I can't receive or test the signal so I can't verify what is actually going on.  As a believer of providing accurate and reliable information it would be contradictory of my standards to provide information that I cant verify or substantiate.

 

If you are offering to supply and fit all the satellite equipment required to receive these signals then I would be happy to provide verified corrections.

 

Regards,

Ian.

Nothing rude at all. All I am saying is instead of moaning about incorrect data, put that effort into submitting correct data.

[IanSav]

Hi Huevos,

 

All the Australian DVB-T data I recently supplied is sourced from the Government data and cross checked with live data from users in all the broadcast areas.  The data is confirmed and verified so I happily supplied it for my recent DVB-T update submission.

 

Am I to understand that you are proposing that unverifyable / untestable submissions should be made to a key data supplier.  Sorry, not from me.  If can't assure that the data I am to provide is appropriate and correct then I won't supply it.  (If there was an option to suggest corrections that the curator can and will verify then that is a different matter.  I don't believe that LyngSat works that way.)

 

Regards,

Ian.

[IanSav]

Hi WanWizard,

 

I just checked out your new satellite.xml build.  Looking good.  One more suggestion / request.  Can you please end the last line with a newline.

 

Regards,

Ian.

[Huevos]

Hi Huevos,

 

All the Australian DVB-T data I recently supplied is sourced from the Government data and cross checked with live data from users in all the broadcast areas.  The data is confirmed and verified so I happily supplied it for my recent DVB-T update submission.

 

Am I to understand that you are proposing that unverifyable / untestable submissions should be made to a key data supplier.  Sorry, not from me.  If can't assure that the data I am to provide is appropriate and correct then I won't supply it.  (If there was an option to suggest corrections that the curator can and will verify then that is a different matter.  I don't believe that LyngSat works that way.)

 

Regards,

Ian.

You just said the data is wrong. Now you say you can't verify it is wrong. Which is it? And please drop the attitude.

[Pr2]

Hi,

 

Lyngsat, kingofsat, etc... are all collaborative sites where any people can report issue and finding, same applies for the lyngsat picon:

 

https://www.lyngsat-logo.com/

 

That's all about people sending update to them.

 

If Australian people are not contributing we cannot do anything about it, since we didn't receive the signal in Europe.

Be sure that all those sites are quite up-to-date for Europe because most of the contributors are from this area.

 

Since you are Australian spread the message around you that those sites exist and needs Australian people to provide accurate informations.

 

About the satellite.xml order in OpenPli the logical is simple, this is an European developed image so it is more logical to start the satellite.xml file with satellite from 0° orbital position.

 

If I install an OE-A image I was first proposed to use the satellite from the other side of the world, now I understand why: because your satellite.xml is generated starting from there.

 

So if you build an image for the USA this make sense, if you build an image for Europe OpenPLi order is more logical.

[ccs]

 

Hi Huevos,

 

All the Australian DVB-T data I recently supplied is sourced from the Government data and cross checked with live data from users in all the broadcast areas.  The data is confirmed and verified so I happily supplied it for my recent DVB-T update submission.

 

Am I to understand that you are proposing that unverifyable / untestable submissions should be made to a key data supplier.  Sorry, not from me.  If can't assure that the data I am to provide is appropriate and correct then I won't supply it.  (If there was an option to suggest corrections that the curator can and will verify then that is a different matter.  I don't believe that LyngSat works that way.)

 

Regards,

Ian.

You just said the data is wrong. Now you say you can't verify it is wrong. Which is it? And please drop the attitude.

 

 

 

He's saying that he can't verify that his proposed changes would be correct.

Edited by ccs, 8 August 2018 - 21:22.

[WanWizard]

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

 

The XML file is meant to be machine parsable, computers don't care at all about order, only about XML syntax correctness. You're not supposed to manually edit it, or even look at it.

 

This lyngsat script has been as far as I can remember, and I am a PLi member since 2006. You're the first one complaining about the order.

 

If it was up to me we dump all these xml files (including bouquets, lamedb, timers, etc) in favour of a database based solution. That would finally end people fooling around in data files as well.

[Huevos]

Lot of changes to that file since 2006. Positions used to float. Anyway let's leave it at that as my input doesn't seem welcome in this thread.

[WanWizard]

Lot of changes to that file since 2006. Positions used to float.

 
Still the same generator. Point remains that, like with your OE-A version, there is no need to manually change the generated file.
 

Anyway let's leave it at that as my input doesn't seem welcome in this thread.

 

Input is always welcome.

 

But "you need to change something because I say so" isn't really a valid reason, you need to come up with something better than that. And sofar I haven't seen anything that leads me to believe we're doing something wrong.

 

This discussion started about the contents of the terrestrial.xml. Of which I said that we don't maintain it, and I don't have a problem having it synced with the OE-A version which is maintainted. Which is what Abu is doing every now and then. There was a reference about it being a lot of work (copy the file and make a PR, we can do that ourselfs if needed), then suddenly the disucssion changed to the satellites.xml, which is and works fine.

 

So what exactly is your problem?

[Huevos]

 

 

This discussion started about the contents of the terrestrial.xml. Of which I said that we don't maintain it, and I don't have a problem having it synced with the OE-A version which is maintainted. Which is what Abu is doing every now and then. There was a reference about it being a lot of work (copy the file and make a PR, we can do that ourselfs if needed), then suddenly the disucssion changed to the satellites.xml, which is and works fine.

 

So what exactly is your problem?

 

Satellites.xml is a complete mess in PLi. Apart from not being human friendly it contains problems. e.g  why are the input streams listed in reverse order? Seeing as this order is used directly in the GUI it affects the user experience.

.
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="16"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="15"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="14"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="13"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="12"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="11"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="10"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="9"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="8"/>
		<transponder frequency="11675000" symbol_rate="30000000" polarization="0" fec_inner="2" system="1" modulation="2" pls_mode="1" pls_code="131070" is_id="7"/>

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

[Pr2]

I must admit Huevos remark is valid about Input Stream it is quite confusing to use it on PLi image.

I scan yesterday IS channels and it was confusing to have the IS in a non-natural order.

[Abu Baniaz]

I use notepad++ to do my editing and sourcetree on windows.

 

I have tried cherry picking the commits between the images, it always bombs out on me with a merge conflict. For me to compare the files and add changes, they need to be comparable in notepad++.

 

To compound things, download of xml files, opens in lf eol. open in notepad++, opens in cr lf

[Abu Baniaz]

Please format the terrestrial and cable files how you want, and I will copy them

[IanSav]

Hi WanWizard,

 

This discussion started about the contents of the terrestrial.xml. Of which I said that we don't maintain it, and I don't have a problem having it synced with the OE-A version which is maintainted. Which is what Abu is doing every now and then. There was a reference about it being a lot of work (copy the file and make a PR, we can do that ourselfs if needed), then suddenly the disucssion changed to the satellites.xml, which is and works fine.

 

This thread was actually started by me to discuss my new "VirtualKeyBoard" code.  That part of this thread is what is important for me and has been completely swamped and lost in all this distraction.

 

Can the TuxBox data elements be moved to their own thread?

 

Regards,

Ian.

[IanSav]

Hi All,
 
I NEVER said that the data in LyngSat *IS WRONG*!  I said:

... some of the information about copies of the Australian FTA to satellite have old details ...

 

This means that what I saw in a text based description of a satellite service does not correspond to what I know is being broadcast on a DVB-T FTA service in that I can access in Melbourne Australia.  For all I know that satellite service *could* be totally unrelated to the similarly named FTA service.

Only ccs has correctly understood what I am saying.  He noted that I am not authorative on any potential corrections as I can't *verify* any changes.  If I can't see what is broadcast on those satellite services then I can't verify that anything I might suggest will be correct or any better than what is there now.

 

Regards,

Ian.

[IanSav]

Hi Abu,

 

I use notepad++ to do my editing and sourcetree on windows.

 

I have tried cherry picking the commits between the images, it always bombs out on me with a merge conflict. For me to compare the files and add changes, they need to be comparable in notepad++.

 

To compound things, download of xml files, opens in lf eol. open in notepad++, opens in cr lf

 

Thank you for telling us what tools you are using.  This is what I use so I can explain what is going on.

 

The repositories are stored on UNIX based servers and the line terminators should all be LF characters.  When you use SourceTree to fetch or check out a file it knows that you are using a Windows based system so as part of the file download the line endings are converted to the Windows appropriate CRLF.  When you edit the files in Notepad++ it will preserve the CRLF until you check the file back in with SourceTree at which time the line endings will automatically be reverted back to the UNIX LF format.

 

If you were a UNIX user on your desktop then the SourceTree / GIT fetch would leave the line endings as LF.  If you were a Mac user on your desktop then the SourceTree / Git fetch would replace the LF line endings with CR to match the Mac line ending format.  Again this would be swapped out on submission back to the repository.

 

If you access the files directly in the repository or download them via the download ZIP option the the files will be delivered in their native UNIX or LF format.  Similarly if the files are exchanged with the repository via FTP then the line endings *CAN* be manipulated to suit the receiving end as appropriate.  I said *CAN* because if you transfer a file in BINARY format then the transfer end of line corrections will NOT happen!  Most FTP transfers determine whether to use TEXT or BINARY transfers based on recognition of the file extension.  In this case if your FTP client knows that an XML files are text based it will use TEXT mode transfer, but if it doesn't know that XML files are text based it will use BINARY mode transfers.  The result would be that on a Windows PC the FTP transferred file would look wrong in any editor that is not aware of the line endings.  Notepad++ would be fine but the normal Notepad would completely corrupt the file (it would delete all the line endings and make a file with a very long single line).

 

While you are trying to diff the different version of the files if you use a diff program that can account for different line endings, like WinMerge, then the comparisons will work properly as you expect.  If you use a program like WinDiff, then it doesn't understand the line endings and will report the files as completely different!

 

In my case when I am working on ANYTHING for Enigma2 I usually always convert all files to UNIX format, LF endings, to avoid all such issues.

 

I hope this post is helpful to understanding what is happening.  If you already know this then I don't mean offence by explaining it.

 

Regards,

Ian.