81 replies to this topic

[VU+NL]

Sinds enige tijd wordt het bestand "satellites.xml" "geleverd" door het image. Bij online updaten wordt het bestand (indien een nieuwere beschikbaar is) ook overschreven. De goede kant daarvan is natuurlijk dat veel gebruikers op deze manier altijd over een up-to-date satelliet- en transponderdatabase beschikken. De slechte kant is dat, als gebruik wordt gemaakt van een zelf aangepast xml-bestand, telkens na een update het eigen bestand moet worden geupload.

Dit is een onhandige situatie, die bovendien in tegenspraak is met de vrijheid die de "open box filosofie" in feite voorstaat.

Mijn verzoek is om een methode in te voeren die het beste van twee werelden biedt: automatische updates indien geen eigen bestand wordt gebruikt en als dat wel het geval is het eigen bestand niet te overschrijven.
Het lijkt me dat daartoe diverse oplossingen denkbaar zijn, b.v op een soortgelike manier als met de skin en de skin_user gebeurt. Dan zou de satellites.xml behandeld kunnen worden op de manier waarop dat nu gebeurt, terwijl een eigen bestand (met b.v. de naam satellites_user.xml) hoger in de hiërarchie zou moeten staan.

[Sjaaky]

> die bovendien in tegenspraak is met de vrijheid die de "open box filosofie" in feite voorstaat.
Dat is wel overdreven gesteld .

Maar de satellieten zijn voor iedereen hetzelfde, dus iedereen zou aan dezelfde satellites.xml genoeg moeten hebben. Als er fouten in zitten dan zouden we daar iets aan moeten doen.

[VU+NL]

Fouten en fouten is twee. Het bekende verhaal: de posities 28.2E en 28.5 E (en dat geldt voor meerdere posities) bestaan beide echt. De meeste lijsten noemen er slechts één, omdat het (voor consumentenschotels: die hebben een veel te grote openingshoek om zo'n klein onderscheid te kunnen maken (en gelukkig: je zou zo'n schotel moeten afstellen)), maar in sommige staan ze beide.

En bovendien: in de huidige situatie wordt de gebruikers xml tijdens het uploaden keurig geschreven; om die vervolgens bij een update weer ongedaan te maken. Dat is natuurlijk heel onlogisch.

[gerrit]

iedere update komt met overschrijvingen... Dat daar dan toevallig ook de sat.xml tussen zit... Dan zou je een changelog moeten maken...
Als die aangeeft dat sat.xml bijgewerkt is, en je wil je oude versie houden, dan zul je hem terug moeten zetten.
Nu weet ik eerlijk gezegd niet of ipkg ook een conditionele overschrijving kan doen.. File already exists.. Do you want to overwrite ?

Persoonlijk vind ik dit voorstel een "veel werk voor een enkeling doen" is.

[Sjaaky]

Houdt ipkg zich zonder te falen aan de writable flag? Dan zou je die gewoon uit kunnen zetten. Wel weer aanzetten voor je gaat editten natuurlijk.

Of je maakt een scriptje dat je na een update runt om alle custom bestanden terug te zetten.

[VU+NL]

iedere update komt met overschrijvingen... Dat daar dan toevallig ook de sat.xml tussen zit...

Uiteraard, maar een update is bedoeld voor systeembestanden, terwijl de satellites.xml eigenlijk een gebruikers bestand is. Mijn "settings" bestand wordt toch ook niet overschreven, en mijn opnames ook niet? Dit is gewoon een, in mijn ogen onlogische, uitzondering.

Houdt ipkg zich zonder te falen aan de writable flag? Dan zou je die gewoon uit kunnen zetten. Wel weer aanzetten voor je gaat editten natuurlijk.

Als dat zo is (hoe kom ik daar achter? Ik weet nooit wanneer er een update komt of was), dan is dat een aardige work-around

Of je maakt een scriptje dat je na een update runt om alle custom bestanden terug te zetten.

Makkelijk gezegd, maar daar ben ik dan weer niet slim genoeg voor!

[MiLo]

"satellites.xml" is zeer zeker geen "gebruikers bestand". Satellieten staan op een bepaalde positie en hebben een lijst met transponders. Als gebruiker heb ik daar geen invloed op, wat ik ook instel, die satelliet blijft mooi hangen waar-ie hangt, en transponders kan ik van thuis uit niet zomaar activeren...

Wat je vraagt is een workaround voor een probleem die onstaat omdat twee website het niet eens kunnen worden of een satelliet op 1.0 of op 0.8 graden staat.

Wat is erop tegen om gewoon de satellites.xml van PLi te gebruiken? Met een find/replace heb je een zenderlijst snel genoeg daaraan aangepast.

[VU+NL]

Nou, hier verschillen we toch wel heel erg van mening:
als vooraanstaande websites het al niet eens kunnen worden over deze zaken, geeft dat wel heel duidelijk aan dat hier niet "de waarheid" bestaat: waarom er dan eentje uitkiezen en die als "de waarheid" opdringen? En daarom is het ook een gebruikers- en geen systeembestand. Ik kan idd geen satellieten en transponders activeren, maar datzelfde geldt ook voor kanalen: ik bepaal zelf wel welke satellieten, transponders en kanalen ik wil gebruiken, daar heb ik geen "opgelegde" lijst voor nodig.
En nogmaals: het is ook zo in tegenspraak met de gehele filosofie.

En wat ik al eerder zei: bij mijn vorige ontvangers, waar ik als gebruiker geen invloed had op de in de ontvanger (met de firmware geïnstalleerde) satelliet- en transponder database, was ik steeds teleurgesteld omdat die lijst nooit of te nimmer werd bijgehouden. En nu ik wel zelf de data kan aanpassen, wordt ik geconfronteerd met op zich keurige updates (want de lijst wordt op deze manier natuurlijk wel up-to-date gehouden) terwijl ik er juist geen/veel minder behoefte aan heb.

Ik weet het: een mens is nooit tevreden en heeft altijd wat te mopperen, maar het zou zoveel mooier kunnen: het goede van twee werelden door de automatische updates te gebruiken zoals nu geregeld is, en daarboven je eigen instellingen kunnen toepassen (waar juist de "open" ontvangers beroemd door zijn).

[WanWizard]

Ik weet niet of het een kwestie is van "niet eens worden". Het zal eerder zijn dat men in 't verleden een "verkeerde" keuze heeft gemaakt, en nu op z'n oud-hollandsch bot weigert een aanpassing te maken.
Terwijl dat een vrij kleine en vooral eenmalige oefening is, en dan zijn we voor altijd van dit gezeik af.

Het gaat daarbij niet over wat je gebruikt, maar wat er is. Dat hoort in de satellites.xml te staan. En dat is voor iedereen precies hetzelfde.

Over welke "vooraanstaande" websites gaat het, en zijn die personen al eens benaderd om dit probleem op te lossen?

[gerard0610]

"satellites.xml" is zeer zeker geen "gebruikers bestand". Satellieten staan op een bepaalde positie en hebben een lijst met transponders. Als gebruiker heb ik daar geen invloed op, wat ik ook instel, die satelliet blijft mooi hangen waar-ie hangt, en transponders kan ik van thuis uit niet zomaar activeren...

Wat je vraagt is een workaround voor een probleem die onstaat omdat twee website het niet eens kunnen worden of een satelliet op 1.0 of op 0.8 graden staat.

Wat is erop tegen om gewoon de satellites.xml van PLi te gebruiken? Met een find/replace heb je een zenderlijst snel genoeg daaraan aangepast.

Dit is inderdaad een steeds weer terugkomend probleem. /images/smiley/sad.gif

Op dit forum zitten over het algemeen mensen die zich al wat verdiept hebben in het een en ander.
"gewone"gebruikers zitten met dit probleem ernstig in hun maag en snappen er niets van.

Ze kennen het trucje HOE een kanalenlijst in hun Dreambox.VU+ te plaatsen.
Zolang ze zich (via het menu) zich aan de "Henksat" houden is er niets aan de hand (geweldig werk van Henk overigens !).
Maar als ze voorkeur hebben voor een andere kanalenlijst en deze (via instructies en een SettingsEditor) in de Dreambox/Vu+ plaatsen is er in eerste instantie niets aan de hand. Door een herstart wordt de nieuwe satellite.xml actief en stellen daar hun satellieten/LNB op af.

Als ze na verloop van tijd OpenPli updaten komt het probleem (indien men geen gebruik heeft gemaakt van de lijst van Henksat) en de "gewone"gebruiker snapt er dan niets meer van.

Natuurlijk ligt het dan niet aan OpenPli maar aan hun eigen onkunde , maar dat begrijpen ze dan niet. Ik denk dat jullie deze ervaring ook wel hebben met deze mensen /images/smiley/sad.gif

Prettig zou het zijn indien er dan rekening met de "gewone" gebruiker rekening gehouden kan worden. Zou het Pli team of anderen hier eventueel rekening mee kunnen houden en eventueel een alternatief proberen te zoeken?

Ikzelf heb hier geen verstand van hoor , dus moet echt dit aan de specialisten overlaten /images/smiley/grin.gif

Bedankt voor al jullie werk !

[VU+NL]

Over welke "vooraanstaande" websites gaat het, en zijn die personen al eens benaderd om dit probleem op te lossen?

KingOfSat en Lyngsat gebruiken verschillende posities voor een aantal satellieten. En de gegevens van KingOfSat zijn nu juist zo mooi, geheel automatisch, met Dreamset binnen te halen. En ja, ze zijn benaderd; hun reactie was, even heel kort samengevat: "wij hebben gelijk".

[gerrit]

Satelites.xml hangt een beetje tussen gebruiker en systeem in..
het definieert waar de box moet gaan zoeken in het spectrum... Dus in die zin is het een systeem bestand...
Alleen....
Enigma gebruikt satelites.xml ook om zenderlijsten te gebruiken.
Dus in die zin kan je zenderlijst "gaten" vertonen als sat.xml gewijzigd wordt. Dus ja.. dan is het weer gebruiker.. Alleen waar leg je de grens.

Ik bedenk me trouwens (schiet me zo te binnen) dat ipkg hier en daar wel vraagt of een bestand overschreven mag worden. Bij fstab bijv.
Deze vlag die deze vraag afdwingt zou je dan ook aan sat.xml mee moeten geven.

[pieterg]

ik zou van sats.xml niet direct een conffile willen maken.
De gebruiker weet toch niet of hij keep/replace moet kiezen, hij heeft die file immers nooit (bewust) geeedit.
Dit in tegenstelling tot een fstab bijvoorbeeld.

[WanWizard]

Is er niet iets te bedenken waarbij gedetecteerd kan worden of de onze er staat, en zo ja, deze overschrijven?

Overigens: ook voor deze file bestaat er toch een "user" versie? Net zoals dat in E1 zo was? Kunnen we dat niet zo handhaven?

Ik zie nu dat die file er op mijn VU 4 keer staat, maar allemaal gesymlinkt naar dezelfde file. Kunnen we onze file niet gewoon in /usr/share neer zetten, zodat de gebruiker een override kan doen door er een in /etc neer te zetten?

[VU+NL]

Ik zie nu dat die file er op mijn VU 4 keer staat, maar allemaal gesymlinkt naar dezelfde file. Kunnen we onze file niet gewoon in /usr/share neer zetten, zodat de gebruiker een override kan doen door er een in /etc neer te zetten?

Kijk: dat lijkt me een voor iedereen eenvoudige en degelijke oplossing.

[MiLo]

De satellites.xml wordt in C code gelezen vanuit "/etc/tuxbox/satellites.xml", al die softlinks zijn waarschijnlijk om ouwe meuk (settings editors enzo) te laten werken.

Een alternatieve satellites.xml zou best kunnen, maar dan moet die OOK in een ipk worden aangeleverd, en niet via een FTP of samba achterdeurtje op de box gepleurd. Via update-alternatives kun je dan laten beslissen welke versie gebruikt gaat worden.

En wat betreft het eigenlijke probleem: Zou iemand willen uitleggen waarom je niet gewoon een find/replace op de settings kunt doen?
(in de MiLo-image tijd had ik zo'n find/replace zelfs in de build zitten om astra2 van 28.4 naar 28.2 te zetten of iets dergelijks).

[WanWizard]

In E1 werkt 't zo dat de default satellites.xml in /share/tuxbox staat, en de user versie in /var/etc.
De code checked of die in /var/etc bestaat. Zo ja, dan wordt deze genomen, zo niet, dan de default die in de image wordt meegeleverd.

In E2 kun je zoiets ook doen. Zet de 'onze' neer in /usr/share, zet in /etc/tuxbox een symlink neer naar die file, en op alle andere plaatsen een symlink naar /etc/tuxbox.
Dat wordt default die van ons geladen, tenzij de user die symlink in /etc/tuxbox vervangt door zijn versie van de file. Dan wordt die gelezen, en wijzen ook gelijk de andere symlinks naar de user file.

Dan hoef je niks te klooien in ipk's, wij werken gewoon onze versie in /usr/share bij net als alle andere systeem files.

En natuurlijk is het een kleine moeite om te zorgen dat overal dezelfde file gebruikt wordt en/of ze gelijk te trekken.
Maar blijkbaar is niemand daarin geinteresseerd, de lijstenbouwers verplaatsen het probleem naar de gebruikers, die 't vervolgens bij ons neerleggen.

[VU+NL]

En wat betreft het eigenlijke probleem: Zou iemand willen uitleggen waarom je niet gewoon een find/replace op de settings kunt doen?

Ja hoor, dat kan ik heel simpel uitleggen:
1- dat is niet het eigenlijke probleem, dat heb ik al een paar maal proberen uit te leggen. Het eigenlijke probleem is dat er automatisch een database in staat/komt die ik niet altijd wil. Eewn "find & Replace is dan hooguit een work-around (die wellicht prima kan voldoen);
2- ik heb geen flets idee hoe een "find & replace" uit te voeren. En in alle bescheidenheid durf ik dan te zeggen dat als ik dat niet weet, dat ook voor hordes andere gebruikers geldt.

in de MiLo-image tijd had ik zo'n find/replace zelfs in de build zitten om astra2 van 28.4 naar 28.2 te zetten of iets dergelijks.

Nou, is dat ook een oplossing/work-around?

[VU+NL]

.......Het gaat daarbij niet over wat je gebruikt, maar wat er is. Dat hoort in de satellites.xml te staan. En dat is voor iedereen precies hetzelfde.

OK, ook goed, maar dan moet je dat ook echt doen en de waarheid vermelden. Dan moet b.v. Eurobird 1 de positie 28.5E krijgen, want daar staat die. Voor de ongelovigen onder u: je mag toch wel aannemen dat de Eutelsat groep weet waar de eigen satellieten staan?

Dat in de praktijk velen die positie afronden naar 12.2E, waardoor een samenvoeging met ASTRA 3 plaats vindt, is een heel andere zaak. Uit praktisch oogpunt is dat wellicht zelfs heel verklaarbaar en misschien zelfs handig: dat vermindert het aantal satellietposities en zo'n klein verschil is voor consumentenschotels toch niet merkbaar. Maar het is en blijft raar een lijst met afrondingen op te dringen aan een gebruiker die, om welke reden dan ook, de echte posities wil gebruiken.

En hetzelfde verhaal geldt voor de andere posities die afgerond worden, zoals Thor 2 (5E) die meestal wordt samengevoegd met Sirius 4 (4.8E) en Intelsat 10-02 (1.0W) die verhaald wordt naar Intelsat 10-02 (0.8W). Zo zijn er nog enkele.

En daarnaast blijft toch mijn principiële punt overeind: een database opdringen en beschouwen als een systeembestand is op zijn zachtst gezegd merkwaardig. Dat die (eenmalig) meegeleverd wordt om vlot een goed werkend systeem te krijgen is natuurlijk wel prima.

[MiLo]

[quote=VU+NL][quote=WanWizard]En daarnaast blijft toch mijn principiële punt overeind: een database opdringen en beschouwen als een systeembestand is op zijn zachtst gezegd merkwaardig.[/quote]

Dat een politiek standpunt, daarover kun je blijven discussieren.

Natuurlijk is zo'n "user" hack wel in te bouwen. Maar ik voel daar niets voor, zolang ik geen echt vat op de onderliggende problematiek heb. Ik denk liever een weekje langer na, om dan met een robuuste oplossing te komen. Aangezien de tuxbox update maar 1x per week ofzo gebeurt, mag het niet zo'n megaprobleem zijn als je dan een paar keer met de hand moet corrigeren.

Ik wil eerst zoeken naar een oplossing waarbij Enigma2 zelf uitplust of een zender te ontvangen is.

Als je kunt afstemmen op 5.0, dan kun je 4.8 daar waarschijnlijk ook ontvangen en vice versa. Voor rotors nog wel lastig - je weet niet bij voorbaat of dat ook echt werkt, maar voor multi-lnb opstellingen is dat juist perfect.

Dat betekent dat dan in satellites.xml de "enige echte" juiste positities komen te staan, zonder afrondingen voor het gemak, en zo te lezen is dat de lijst die jij nu gebruikt.

Wil je een workaround? De volgende methode zorgt ervoor dat hij niet meer bijgewerkt wordt:

ipkg files tuxbox-common
(maak een kopie van die files, softlinks zijn vaak niet nodig. Je kunt ook met 7-zip kijken wat er in een ipk zit)
ipkg remove tuxbox-common
(zet de kopieen terug)