81 replies to this topic

[gerard0610]

Ik zou 't ook wel graag willen begrijpen.

Want 't oorspronkelijke probleem ging over het feit dat bij een update van de E2 image de satellites.xml werd overschreven. En dat is bij een E1-CDK image (500/5600/7000 box) niet mogelijk. Want daar bestaan geen online updates voor.

Misschien kun je eens uitleggen wat je precies doet, en wat je dan verwacht dat er (wel of niet) gebeurd.

Het lijkt er op dat we elkaar toch niet goed begrijpen.

Omdat het voor ons veel waard is om ook Enigma 1 (dus nietde DM500 alleen , maar de gehele reeks) het probleem via het overschrijven van de satellites.xml op te lossen zal ik omschrijven hoe ik Open-Pli update.

Ik zal het een en ander ‘uitgebreid’ omschrijven zodat iemand die er van stand van heeft dit kan vertalen in hoe de software werkt en, naar wij hopen, een aanpassing kan maken dat wij de de gebruikte satellites.xml kunnen overschrijven en dat deze door de update van OpenPli niet overschreven wordt.
Ik kan die slag helaas niet maken omdat ik er totaal een verstand van heb.

Daar gaan we.

Ik heb een DM500S (Engma1)
Je kan het MENU updaten door: Blauwe toets – Software beheer - Download Latest menu.
Maar… over deze gaat het dus niet.

Menu – Instellingen – Systeem instellingen – Software updates– Internet update en dan krijg je inderdaad meerder mogelijkheden te zien:
Zoals: ‘OpenPli-unstable-dm500 image (20100816)’ d.w.z. tussenhaakjes is de datum (= 16 Aug 2010).

Daaronder staat het zelfde maar dan met ed toevoeging ….-‘old-framebufferimage’: Dit is slechts voor hele oude DM500’s dus voor de meeste n.v.t.).

Deze 2 herhalen zich dan twee maal en wel voor de dag eerderdan de eerste datum en nogmaals maar dan 2 dagen eerder.

Vervolgens ga ik m.b.v. DCC kijken waar er satellites.xml staan en doe ik d.m.v. de zoekcode in Telnet: ‘find / -name satellites.xml’
Je ziet dan dat deze op 2 plaatsen staat:
- /share/satellites.xml maar dat is een link naar /tuxbox/satellites.xml
- /share/tuxbox/satelliets.xml en inderdaad hier staat de satellites.xml en is daarmee de enige die er (nu) in zit.
Note: In /var/ staatdus inderdaad geen satellites.xml
Aan de inhoud van de satellite.xml kan ik zien dat hij van PLI (via Lyngsat) is, want er staat in:
‘Created By Pli Lyngsatgrabber Version 20100616
Built at Sat 14-08-2010
04:04:54’

Bij de satellites.xml staat er deze regels niet en is daarmee herkenbaar.

Ik gebruik DreamSet V2.30 voor de upgrade. Ik heb ook DreamBoxEdit (DBE) V3.0.1.5.EHAD, maar die geeft hetzelfde resultaat.

Voor de satellites.xml verwijst DBE naar /var/etc/ (drukknop Satellite reciever) en
DreamSet ook naar /var/etc/

Bij DBE geeft de test ‘Ip connection’en ‘username check’ demelding OK.

Bij DreamSet daarentegen geeft hij voor de satellites.xml een ‘warning’. Dit is logisch omdat we zojuist geconstateerd hebben dat in/etc/var/satellites.xml geen satellites.xml staat.

Als ik dan m.b.v. Dreamset (of DBE) onze kanalenlijst uploaden gevolgd door een ‘reload’commando dan staat er daarna zie ik dat met FIND via telnet zie dat er 4x satellites.xml gevonden is en wel:

- /share/satellites.xml maar dat is een link naar /tuxbox/satellites.xml
- /share/tuxbox/satelliets.xml (deze is van Pli-Lyngsat)
- /var/etc/satellites.xml
- /var_flash/etc/satellites.xm l( ook deze is die ik zelf mbv DReamSet geupload heb)

Daarna in de DM500 gekeken:
Menu – Instellingen – Satellieten en transponders – satelliet configuratie : hier kan ik alleen 28,2 E selecteren en niet 28,5E
Zo ook 0.8W en niet 1.0W.

Ook na een Harde reboot (stekker er uit en er weer in) bleef alles zoals het was. Ook bij de selectie in de DM500 kon ik niet de 28,5E en1.0W zien.

Conclusie: desatellites.xml wordt bij Open-Pli niet (zodanig) overschreven
dat ik in de DM500 de eigen upgeloadesatellites kan zien.

Vreemd is WEL dat ik de 1W en 23,5 E in de DM500in Menu – Instellingen – Satellieten en transponders – Transponder-edit.

Gezien de sat posities overeenkomen met mijn kanalenlijst is dit dus de eigen Satellites.xml en niet die van Pli (lyngsat).

Vraag: Waar staat deze satellites.xmldan en kan je die dan door de DM500 laten gebruiken en verplaatsten naar deplaats waar Enigma1 in de dagelijkse operatie deze gebruikt?

Ook als ik op 1W ga staan en deze opsla zie ik deze later nog niet terug in de DM500bij Menu – Instellingen – Satellieten en transponders – satelliet configuratie
Ook een harde reboot helpt niets.

Tot slot: tegen beter weten heb ik nog geprobeerd om de satellites.xml in /share/tuxbox/.
Maar deze kan je inderdaad niet overschrijven.

Hopelijk kan iemand ons helpen.

[WanWizard]

/var is een symlink. Als je de /var niet hebt verplaatst dan wijst deze naar /var_flash, dus die twee files die je daar vind zijn dezelfde.

Als je op sommige plaatsen jou versie van de satellites.xml (in /var/etc) niet ziet, dan is dat een bug die gefixt moet worden, want deze dient overal een override op de standaard lijst (in /share/tuxbox) te zijn.
Dat lijkt hier niet het geval, hoewel ik dit nog nooit op mijn 7000 heb gezien (ik gebruik ook een custom lijst). Als ik weer thuis ben zal ik eens kijken of ik dit reproduceren kan.

[gerard0610]

WanWizard,

Dat zou fijn zijn.
We wachten even af

Bedankt zover.

[VU+NL]

'k Heb een beetje zitten grasduinen in de code vanmorgen, en daar werd ik niet blij van. Ik dacht dat het hele LNB selectie gedoe wel in Python zou zitten (handig met lijstjes schuiven enzo) maar da's dus in C code gedaan. Dat kost gewoon teveel uren voor zoiets 'flauws'.

Ik ga dus simpelweg het volgende inbouwen: Als een satellites.xml in /etc/enigma2 bestaat, dan wordt die geladen, en niet die in /etc/tuxbox.

In /etc/enigma2 doet hij dan vanzelf met een eventuele backup/restore mee. Normale gebruikers hebben hier dan geen last van.

Ik wilde nu eens de originele .xml (die dus in /etc/tuxbox staat) vergelijken met mijn eigen versie in /etc/enigma2. Maar wat schetst mijn verbazing: beide zijn gelijk!
Met andere woorden: de versie van de image is blijkbaar overschreven door mijn versie. Dat is toch nooit de bedoeling geweest? En zo kan je toch ook niet meer "terug naar de fabrieksinstellingen? Of zie ik nu iets over het hoofd?

[MiLo]

Heeft je settings editor de versie in /etc/tuxbox misschien vervangen?

[VU+NL]

Heeft je settings editor de versie in /etc/tuxbox misschien vervangen?

Nee: die staat heel bewust ingesteld op etc/Enigma2.

Maar dat staat die pas, sinds jouw oplossing bestaat: heb ik dan de situatie van daarvoor (toen die nog wel op de tuxbox stond ingesteld)? Zo ja: wanneer komt de volgende update? Dan kan ik zien of de verwachte situatie idd bestaat.

[MiLo]

Je zou met ipkg de "tuxbox-common" kunnen forceren, dus remove/install, of er is ook een "reinstall" force optie dacht ik. Dan moet je toch de versie uit de feed hebben.

[VU+NL]

Ik bedenk me net dat ik heel recent (= na die update) heb geflashed, dus het kan geen "geërfde" situatie zijn.

[pieterg]

controleer eens of de ene geen symlink naar de andere is?
Dat twee files toevallig hetzelfde zijn is niet waarschijnlijk.

Overigens, als mensen verschillende sats.xml gaan gebruiken heeft dat wel wat gevolgen.
Ten eerste de settinglijsten uit de downloads, die niet meer gaan werken (maar dat was bekend, en geen probleem als je juist je eigen settinglijsten wilt gebruiken).
Maar ten tweede gaan ook een aantal piconsets niet meer werken.

Dus voortaan als iemand meldt dat picons niet werken, niet vergeten naar sats.xml te vragen.

[VU+NL]

controleer eens of de ene geen symlink naar de andere is?
Dat twee files toevallig hetzelfde zijn is niet waarschijnlijk.

Ze waren idd niet identiek: die in de tuxbox was van voor mijn laatste wijziging aan de xml. Ik zit nu toch heel sterk te twijfelen of het niet mijn eigen file is van voordat Milo die wijziging doorvoerde (en toen de editor dus wel naar de tuxbox verwees). Ik zal bij gelegenheid weer eens schoon flashen.

Overigens, als mensen verschillende sats.xml gaan gebruiken heeft dat wel wat gevolgen.
Ten eerste de settinglijsten uit de downloads, die niet meer gaan werken (maar dat was bekend, en geen probleem als je juist je eigen settinglijsten wilt gebruiken).

Is dat wel zo? Gaan die on-line lijsten niet vergezeld van een satellites.xml? En zo nee: zou het dan geen goed idee zijn dat wel te doen?

Maar ten tweede gaan ook een aantal piconsets niet meer werken.
Dus voortaan als iemand meldt dat picons niet werken, niet vergeten naar sats.xml te vragen.

Hmmm, die hangen toch aan een servicereference, en niet aan een transponderdatabase? In ieder geval kan ik melden dat ik een geheel andere satellite.xml gebruik en dat de (online verkregen) picons het prima doen.

[pieterg]

Overigens, als mensen verschillende sats.xml gaan gebruiken heeft dat wel wat gevolgen.
Ten eerste de settinglijsten uit de downloads, die niet meer gaan werken (maar dat was bekend, en geen probleem als je juist je eigen settinglijsten wilt gebruiken).

Is dat wel zo? Gaan die on-line lijsten niet vergezeld van een satellites.xml? En zo nee: zou het dan geen goed idee zijn dat wel te doen?

Meerdere ipk's kunnen niet dezelfde bestanden installeren. Daarom kunnen settinglijsten geen sats.xml bevatten. In online settinglijsten moeten de orbital posities overeenkomen met wat in sats.xml staat.

Maar ten tweede gaan ook een aantal piconsets niet meer werken.
Dus voortaan als iemand meldt dat picons niet werken, niet vergeten naar sats.xml te vragen.

Hmmm, die hangen toch aan een servicereference, en niet aan een transponderdatabase? In ieder geval kan ik melden dat ik een geheel andere satellite.xml gebruik en dat de (online verkregen) picons het prima doen.

De problemen zijn er alleen voor die orbital posities welke afwijken van wat lyngsat hanteert (en dus in de sats.xml en de piconsets staat)

[VU+NL]

Overigens, als mensen verschillende sats.xml gaan gebruiken heeft dat wel wat gevolgen.
Ten eerste de settinglijsten uit de downloads, die niet meer gaan werken (maar dat was bekend, en geen probleem als je juist je eigen settinglijsten wilt gebruiken).

Is dat wel zo? Gaan die on-line lijsten niet vergezeld van een satellites.xml? En zo nee: zou het dan geen goed idee zijn dat wel te doen?

Meerdere ipk's kunnen niet dezelfde bestanden installeren.

Dat kan ik volgen. Maar waarom zou die online versie niet, net zoals een door de gebruiker geplaatste versie, in de etc/enigma2 kunnen komen? Dan moet het toch altijd goed gaan?

[VU+NL]

Het vermoeden dat ik hier uitsprak was dus wel correct (en voortaan zal ik niet meer zo snel aan mijzelf twijfelen):
als de gebruiker een Satellites.xml plaatst in etc/Enigma2 wordt het originele "fabrieks"exemplaar in etc/tuxbox daar wel degelijk mee overschreven. Ik heb nu verschillende malen een eigen xml geplaats en dat na de herstart vergeleken met die in de tuxbox.
Dit kan volgens mij niet de bedoeling zijn: nu hebben we in feite de omgekeerde situatie van voor MiLo's ingreep (toen werd het exemplaar van de gebruiker juist overschreven).

[pieterg]

er bestaat waarschijnlijk nog een symlink?
(iets over een symlink heen copieren vervangt meestal de doel lokatie van de symlink)

[MiLo]

Hoe "plaats" je die? Met FTP ofzo?

[VU+NL]

n.a.v. je eerdere post heb ik me daar een slag in de rondte naar gezocht: niets kunnen vinden. Maar mag ik de bal een beetje terugkaatsen: als er zo"n link zou zijn, zou jij dat moeten weten. Ik heb op dat gebied helemaal niets zelf ingericht. Ik heb een standaard installatie (en die ken jij veel beter dan ik dat ooit zal doen), en ik plaats settings, inclusief die .xml, in etc/enigma2. En vervolgens constateer ik bij herhaling dat na een trboot de .xml in de tuxbox dezelfde is (geworden).

[pieterg]

ik ken de oorspronkelijke setup, en daar wordt gebruik gemaakt van symlinks.
Ik vraag me dus af of na de wijziging die symlink ook echt verdwenen is.

[VU+NL]

Kan jij dat verder uitzoeken? Ik zou niet weten hoe dat te doen. Ik kan alleen reproduceren wat ik hierboven heb gezegd.

[MiLo]

/etc/enigma2 heeft normaal gesproken geen symlinks naar satellites.xml. Ik heb ze overigens allemaal verwijderd, werden toch nergens voor gebruikt.

[VU+NL]

Kan jij dat verder uitzoeken? Ik zou niet weten hoe dat te doen. Ik kan alleen reproduceren wat ik hierboven heb gezegd.

Nou, ik ben er eindelijk achter wat de oorzaak is: ik gebruik als editor (ook) SetEditDreambox, en het blijkt nu dat die de .xml toch stiekem in etc/tuxbox plaatst, ondanks dat de instellingen in die editor wel goed staan. Met DreamboxEdit en SetDream doet dit probleem zich dan iik niet voor.
Sorry voor de veroorzaakte verwarring: de oplossing van MiLo werkt dus gewoon prima en er is verder helemaal niets mis.