87 replies to this topic

[littlesat]

The only way to really solve this tenths in degrees issue is to make a change in e2.... that it does not look for the exact value but for a value that is the most close by in your setting with a max deviation (e.g. 0.3 degrees)....

[Rob van der Does]

Nope, not the only way; I gave you a fine alternative that you can implement a la minute without making any changes.....

Edited by SatKiekerd, 8 April 2014 - 07:24.

[Erik Slagter]

I see another workaround coming in our satellites.xml generation script.

[Huevos]

The only way to really solve this tenths in degrees issue is to make a change in e2.... that it does not look for the exact value but for a value that is the most close by in your setting with a max deviation (e.g. 0.3 degrees)....

That is not an option. Some satellite positions are legitimately 0.3º apart. So allows you a maximum of 0.2º. And when you take the 0.1º shift of C-band into account that gives 0.1º of leeway which would not correct the 0.3º error at 7W.

 

Correct way to handle this is at satellites.xml creation time. At least that way if there is an error in the data at least a layman can sort it out. If you code it into E2 and later there were a problem only people who can edit E2 (in whichever language the changes were made in) would be able to sort it out. And are you going to change your algorithm every time Lyngsat decide to do something new?

 

BTW, since OpenViX has been directly creating it's own satellites.xml file there have been none of these events in more than 2 years. Data is always less than 7 days old and all major positions are fixed. The process that collects the data emails the created satellites.xml and it just has to be committed. If there were ever an issue with any positions it would be seen at commit time, but so far that has never happened.

Edited by Huevos, 8 April 2014 - 08:38.

[Erik Slagter]

Aparently they have even more workarounds in their generation script than we already have.

[Huevos]

Aparently they have even more workarounds in their generation script than we already have.

Not sure what workarounds OpenPLi has, but one of the important ones in OpenViX is no inactive feed frequencies, as these just slow down service scans for no possible benefit.

Edited by Huevos, 8 April 2014 - 08:47.

[WanWizard]

We have that filter too.

[Rob van der Does]

The only way to really solve this tenths in degrees issue is to make a change in e2.... that it does not look for the exact value but for a value that is the most close by in your setting with a max deviation (e.g. 0.3 degrees)....

 

Nope, not the only way; I gave you a fine alternative that you can implement a la minute without making any changes.....

Not even a correct way.

You have a track record of not wanting to work-around issues in E2 (a stance I can perferctly understand), and now you would be willing to do that for no good reason?

Feeding E2 with non-existent (i.e. virtual) data and then working around it in E2??

[Erik Slagter]

Aparently they have even more workarounds in their generation script than we already have.

Not sure what workarounds OpenPLi has,

We have workarounds for 23.5 and for 4.8 because Lyngsat says they're 23.2 and 5.0 respectively.

but one of the important ones in OpenViX is no inactive feed frequencies, as these just slow down service scans for no possible benefit.

I added this feature myself over a year ago. It skips feeds and testcards. It has been wrong for some time though, due to these options not being activated, it should be okay now again.

Edited by Erik Slagter, 8 April 2014 - 11:25.

[Huevos]

We have workarounds for 23.5 and for 4.8 because Lyngsat says they're 23.2 and 5.0 respectively.

Not any more. 23.5E is back at 23.5E And 4.8E is now 4.9E. There are others too. 21.6E is 21.5E on Lyngsat, and 7.0W is 7.3W. And that's the problem, they are forever changing. If the workarounds are for specific cases you are going to need a new workaround for each specific case and that means having a person involved. If you are going to edit this creation script maybe have it send an email to someone for approval whenever it detects a new position.

 

 

I added this feature myself over a year ago. It skips feeds and testcards. It has been wrong for some time though, due to these options not being activated, it should be okay now again.

OpenViX has had it a couple of years and uses the satellites.xml data in blindscan to check if transponders are known DTH. If feed/inactive transponders were in there this would not be possible.

[Erik Slagter]

Of course I am not fully aware of what other image builders do.

The thing is that really most users use "settings list" so whatever effort you take to make the satellites.xml "perfect", not many users will benefit from it. Don't get me wrong, I do think we should supply a proper satellites.xml file, but the effort to keep it "perfect" doesn't weigh up to number of users using it.

OTOH if ViX does have a "perfect" file because someone it willing to spend the time on it, why duplicate the effort? I can't speak for the rest of the team, but I don't have an objection to share ViX's versions, if ViX is ok with it.

[Huevos]

 I don't have an objection to share ViX's versions, if ViX is ok with it.

Well it's there on the git and also satellites-xml.org (which is an OpenViX team member project). As for settings I'm currently working on a solution for this. You upload the settings.zip file. Lamedb is corrected and satellites.xml is replaced with a compatible version. And then the zip file is returned with the changes in it.

[Rob van der Does]

The thing is that really most users use "settings list" so whatever effort you take to make the satellites.xml "perfect", not many users will benefit from it.

I don't think that's correct.
All the settings-files on the PLi-feeds have no satellites.xml, so they (and hence their users) depend on the system file in etc/tuxbox. So a satellite-position changing for no good reason will require the tuner-config to be adjusted accordingly.

[Erik Slagter]

If I understand this correctly, if the people that make the settingslist use the "correct" satellites.xml file, I guess there is no need for correction of the lamedb?

[Huevos]

If I understand this correctly, if the people that make the settingslist use the "correct" satellites.xml file, I guess there is no need for correction of the lamedb?

Exactly, but that means relying on them to use the correct file in the first place.

 

The way I talked about above pulls the positions in lamedb to match the image's default satellites.xml and flags any positions that are "unknown".

Edited by Huevos, 8 April 2014 - 12:54.

[Rob van der Does]

The positions in the lamedb are used for tuning; the position in the XML for scanning.
But in the tuner config: say you had a tuner set to satellite X at position 0.00 and all of a sudden the satellite is at 0.03 the tuner config isn't correct.

And about making settings using the 'correct' xml: that is onoy temporarely; next time the position has been changed, while the settings (and hence the lamedeb) are still the same.

Edited by SatKiekerd, 8 April 2014 - 12:52.

[Erik Slagter]

I don't have anything to do with whatever settingslist (don't use them) nor do I have a rotor, so I guess I am not the appropriate person to have an opinion about this. I only require the satellites.xml to have all active transponders and nothing else.

[SpaceRat]

The thing is that really most users use "settings list"

There is absolutely nothing I would take into doubt even more.

The very first thing I heard from a friend to whom I recommended a Vu+ Duo² was:
"The favorite list is a pile of junk, I'm currently doing a full scan."

And it's not only him, I know nobody using a "pre-sorted" list.

You would need "bouquet maintainers" from all around the world and each and every country or even state to maintain "settings lists" which would suit even a noticable small amount of users.

See Germany for example:
The "older generation" still mostly orders stations like they came up after World War 2:
1. Das Erste ("The first" or "First German television")
2. ZDF ("The second" or "Second German television")
3. Their local "third program"

The "third program" varies from state to state or even county, e.g. for North-Rhine Westphalia it would be "WDR", which has different local programs for
- Aachen
- Bonn
- Cologne
- Dortmund
- Duisburg
- Düsseldorf
- Münster
- Wuppertal
- ...

The same is true for all other "third programs" in Germany (BR3 -> Bavaria North, Bavaria South, MDR -> MDR Thüringen, MDR Sachsen, MDR Sachsen-Anhalt, NDR -> NDR Niedersachsen, NDR ...)
and also for ORF in Austria:
ORF 2 exists with various local programs:
Wien, Niederösterreich, Steiermark, ....

In Germany, older people then usually tend to use the closest "third program" as fourth, especially if they used to live at state borders and were able to receive those third program even back in the antenna days ...
So for southern NRW, we likely get this order:

Das Erste, ZDF, WDR Bonn (or Cologne in the county of Euskirchen ...), SWR Rheinland-Pfalz (Rhineland-Palatine)
while in northern NRW, county of Kleve, it could be like this:
Das Erste, ZDF, WDR Duisburg, NDR Niedersachsen
in the Siegerland, it would probably look like this:
Das Erste, ZDF, WDR Siegen, hr-Fernsehen
and so on and so on.

For the "it has always been that way"-people, this order is a must and you would need to provide HUNDREDS of different settings lists for Germany alone, just to suit those "most important" part of the list.

Next, nobody would split his favorites into HD and non-HD or into that many bouquets at all. Normal people use ONE bouquet with all the stations they watch. All settings lists I know are cluttered into parts in a totally senseless way.

So:
No, I guess only absolute beginners will use a pre-defined station list and they won't even be happy with it, just too helpless to fix it.
For me, the settings list was the first package to remove as soon as it destroyed my proper own one for the first time. The idea that the settings list could overwrite my favorites was too absurd to me at the time I installed the settings list ...

My next enhancement suggestion would have been to split those "settings list" into the usefull part - proper satellites.xml plus a full scan of the satellites within (lamedb) - in one package and the silly bouquets in another package (Which probably nobody will continue to use ...).

[Huevos]

The positions in the lamedb are used for tuning; the position in the XML for scanning.
But in the tuner config: say you had a tuner set to satellite X at position 0.00 and all of a sudden the satellite is at 0.03 the tuner config isn't correct.

Yes agreed. Most important thing is lamedb and satellites.xml are a complimentary pair. Changing them individually can only lead to problems.

I don't have anything to do with whatever settingslist (don't use them) nor do I have a rotor, so I guess I am not the appropriate person to have an opinion about this. I only require the satellites.xml to have all active transponders and nothing else.

That makes no difference. Even if you only have a fixed dish the position of that fixed dish in satellites.xml still needs to correspond with the values in lamedb otherwise the tuner will need to be reconfigured for the channels to be tuneable.

[WanWizard]

@SpaceRat,

 

Our experience is different. You are clearly a power user, most OpenPLi users aren't.

 

I'm not saying everyone uses HenksatSettings, but most use some form of pre-cooked settingslist, either through a "Fastscan" solution offered by the provider, through a list they download from somewhere (and which maintains their local channels), or a list compiled by the handy nephew or neighbor that advised them an Enigma box...