30 replies to this topic

[alexyug]

Hello everyone.

Is there any plugin available to automate the process of updating sattelites.xml file?

[christophecvr]

I already mentionned this long time ago.

 

The base sattelites.xml into openpli is not good.

 

First it's many times out of date.

 

But especially it does contain a lot off autosettings which are not supported by all tuners.

 

The result is that scan made on vuduo2 for example will not work fully ok on dm8000.

 

Best made You're own sattelites.xml using :

http://satellites-xml.org/

 

website.

Edited by christophecvr, 29 September 2014 - 12:12.

[Erik Slagter]

Updating should normally be automatic. Problem is that the process of obtaining the data from lyngsat is cumbersome and prone to error. This, compared with the fact that most people are using prefabricated "settingslist" it's not very rewarding to spend a lot of time (which we already did in the past, btw) on this issue.

 

For most services the supplied xml file will be just ok. If you have "very special" transponders, it's quite easy to scan them manually.

[Rob van der Does]

Erik, you have said multiple times before that you were going to use https://github.com/o...e-tuxbox-common which is being updated (and checked) weekly. Still WiP?

[Erik Slagter]

Suggested not announced...

[SpaceRat]

Erik, you have said multiple times before that you were going to use https://github.com/o...e-tuxbox-common which is being updated (and checked) weekly. Still WiP?

That one isn't any good either.

[SpaceRat]

Example:

Real data: 11 171 MHz horizontal (DVB-S2, Symbolrate SR 22 000, Fehlerkorrektur FEC 3/4, 8PSK)

Edited by SpaceRat, 30 September 2014 - 09:01.

[SpaceRat]

Example:

Real data: 11 171 MHz horizontal (DVB-S2, Symbolrate SR 22 000, Fehlerkorrektur FEC 3/4, 8PSK)
Active since April 2014


Errors marked in bold:

Lyngsat/oe-a (Update 2 days ago):
<transponder frequency="11171000" symbol_rate="22000000" polarization="0" fec_inner="3" system="1" modulation="2"/>

Lyngsat/oe-a (Update 7 days ago):
Transponder entirely missing.

Satellites.xml.org:
Transponder entirely missing.

vHannibal:
<transponder frequency="11171000" symbol_rate="22000000" polarization="0" fec_inner="2" inversion="2" modulation="2" system="1" pilot="2" rolloff="0"/>


LyngSat and Satellites.xml.org can be considered as random garbage at best.
vHannibal is at least close (And usually it's right).

I wonder where the problem in creating a proper satellites.xml is ... isn't there any official source for the data?

[Huevos]

Spacerat, that transponder is present at Lyngsat, king-of-sat, satellites.xml.org, https://github.com/o...e-tuxbox-common, and in the network table. So all you need to do is a network search and the transponder will be scanned in (as long as you don't have a deficient receiver). Also, I've checked the parameters of the transponder with the analyzer and the parameters given in all those places are correct.

 

Occassionally some transponders may not be present on Lyngsat and if that is the case all you have to do is submit an update and then Lyngsat and all other sites that use it as a reference will be updated.

 

And TBH, what is closer, a list that contains 11 dead transponders on 19.2E, or one that needed FEC on one transponder updated? And anyway whoever's list you are going to use it will only ever be a snapshot of the state of affairs at some time in the past.

[Huevos]

isn't there any official source for the data?

No!

[el bandido]

The transponder information changes a lot and sometimes is not widely published here in the United States so we have to rely on blindscan or other sources for transponder information.

The blindcan plugin has been very helpful but it would be nice if it had an option to write the found transponders directly to the satellite .xml file. We can save the blindscan found transponders to a separate .xml file now, but it would be a help to us if we had another option to save the found transponders directly to the main satellite .xml file.

[SpaceRat]

Spacerat, that transponder is present at Lyngsat, king-of-sat, satellites.xml.org, https://github.com/o...e-tuxbox-common,

It is now, after the stations went on.

And TBH, what is closer, a list that contains 11 dead transponders on 19.2E, or one that needed FEC on one transponder updated? And anyway whoever's list you are going to use it will only ever be a snapshot of the state of affairs at some time in the past.

Closer is easy:
The list which allows finding a new station using the data provided by the operator.
If a new station comes on and I know its transponder already, I just do a scan on that single transponder. No blind cow, network or voodoo scan, I just want to scan the fucking true transponder.

I don't want to have a list decide for me, what's good for me and what's not.
The mentioned transponder has been on sine months and the data for the new stations has been communicated for months too.

If I can't do a scan on the communicated transponder (Because it's missing from config) on the start date of a station, that's a clear error.
On the other side, when there are 11 "dead" transponders that's nothing, because the transponders aren't "dead" as you call it, there is just no broadcast on it, so no stations will be found and everything is fine.

Skipping "dead" transponders would only be ok if you could ensure that it will be added early enough to propagate through merges, updates and so on before the stations come live, so that every user can find them when they come live ... and not one week later after the transponder has been marked as not-dead-anymore in Timbuktu and propagated through the merge-/pull-/update-chain.

[Rob van der Does]

.... I just want to scan the fucking true transponder.

There's no such thing....

I don't want to have a list decide for me, what's good for me and what's not.

Exactly, that's why you can network/blindscan.

[Huevos]

I don't want to have a list decide for me, what's good for me and what's not.

Well create your own then and save it as user file. That way it won't be over written when you update your image.

 

 

Spacerat, that transponder is present at Lyngsat, king-of-sat, satellites.xml.org, https://github.com/o...e-tuxbox-common,

It is now, after the stations went on.

I haven't got a crystal ball, so I can't incorporate changes to satellites.xml before they happen.

Edited by Huevos, 30 September 2014 - 21:33.

[Rob van der Does]

Well create your own then and save it as user file. That way it won't be over written when you update your image.

After all that's why PLi(-based)images have this ingenious system of a system-file in /etc/tuxbox (that is perfect for 99.9% of the users and is being maintained for you) and a user-file in /etc/enigma2 (for the other 0.1%). They don't bite each other.

Edited by SatKiekerd, 30 September 2014 - 21:49.

[SpaceRat]

Spacerat, that transponder is present at Lyngsat, king-of-sat, satellites.xml.org, https://github.com/o...e-tuxbox-common,

It is now, after the stations went on.

I haven't got a crystal ball, so I can't incorporate changes to satellites.xml before they happen.

You either play stupid, are stupid or a troll.

As mentioned a zillion times before:
Those transponders were on since months and/or vHannibal had a crystal ball.


I won't discuss your ignorance any longer.
I just wanted to point out that both, OpenPLi and oe-a, intentionally keep using outdated sources for transponders, which is an undeniable fact and thus miss the chance to have up-to-date satellites.xml right from the feed.

There is no sense in discussing your beliefs, e.g. in the holy trinity or whatever, an existing and documented transponder is nothing to believe in or not, it's a plain technical fact.

A street with a name is a street with a name is a street with a name is a street with a name is a street with a name is a street with a name is a street with a name is a street with a name and will always stay a street with a name, regardless how long you keep denying it, just because the houses along are are currently under construction.

A good map will contain those streets, your's won't. I got that much, but it doesn't make your map correct.


I surely know how to help myself by removing the package with the broken satellites.xml and maintaining satellites.xml myself.

Sorry for trying to help others who can't to have a good satellites.xml too.

Edited by SpaceRat, 30 September 2014 - 23:20.

[Huevos]

vHannibal had a crystal ball.

Yes, but you've already said above that the parameters in his list for that transponder were wrong.

 

A street with a name is a street with a name is a street with a name is a street with a name is a street with a name is a street with a name is a street with a name is a street with a name and will always stay a street with a name, regardless how long you keep denying it, just because the houses along are are currently under construction.

Eleven transponders, not just empty, but not even powered up... Great idea for slowing down scans.

 

Anyway, I really don't see why you are so fixated over this one transponder that only went into DTH service a couple of days ago and would have been found with a network search by any decent receiver.

[SpaceRat]

vHannibal had a crystal ball.

Yes, but you've already said above that the parameters in his list for that transponder were wrong.

Indeed, that's why I asked about official sources.

 

[A street is not a street before the first house is finished]
Anyway, I really don't see why you are so fixated over this one transponder that only went into DTH service a couple of days ago and would have been found with a network search by any decent receiver.

It's not the first time this happened.

You keep telling us that a street, even if officially named and marked with street signs, does not belong inside a map before the first house there is finished.

2014-04-07 - Sky: New transponder ready
2014-08-29 - Sky: Three new stations to launch by end of September - one on the transponder mentioned before

You should really simulate reading those articles ... even if you do not speak German you will find out it mentions all the data of the new transponder.
How could they know them almost half a year ago if the transponder was fictious by then?


You are even right to a certain degree:
We would not need empty transponders in the list ... if E2 would have automatic real time updates for satellites.xml (which it doesn't), so that when a station goes live the previously omitted transponder gets automatically added in time.
And you are also right when you claim that the satellites.xml on the box effectively is just a picture of the past.

So you yourself are providing all the reasons necessary to understand why "dead" transponders are not to be censored out of the list:
Because it really is a picture of the past, including reliable future data is the only way to reduce the delay inside the flow of information.

This is also what good map makers do. In the age of printed maps they included streets "under construction" or even "planned" ones and in the age of digital maps they include streets as soon as they get their hand on legally binding land-use plans containing those streets ... because that's the only way they can already have those streets inside a satnav when the user needs them although there is a usual 6 months delay between the last cartographic revision and the shipping date.

And it's no excuse that a more sophisticated search would have found the transponder if a simple "single transponder" scan would have done the job.

I don't know where you come from and how stations handle it there, but here the stations usually want to have viewers and publish all the relevant information required to find their station(s).
Whenever a new station starts, a single transponder scan is all I need to do ... as long as the transponder didn't get censored.
I do not need to perform full scans, network scans, blind scans, or whatever.

Edited by SpaceRat, 1 October 2014 - 02:27.

[Rob van der Does]

I surely know how to help myself by removing the package with the broken satellites.xml and maintaining satellites.xml myself.

There we go again: you don't have to remove anything at all.
It has been explained to you several times, that you can use a user-file besides the system-file.
Changing the system-file for your personal needs is no good, as it will be overwritten on the next image update.

[SpaceRat]

I surely know how to help myself by removing the package with the broken satellites.xml and maintaining satellites.xml myself.

There we go again: you don't have to remove anything at all.
It has been explained to you several times, that you can use a user-file besides the system-file.

It's borked and I don't like the idea of having broken stuff on my box.
 

Changing the system-file for your personal needs is no good, as it will be overwritten on the next image update.

It won't *g*

opkg remove tuxbox-common
or
chattr +i /etc/satellites.xml