EPG Daten verschwinden immer wieder

[tecfreak]

Hallo,

ich habe bei meiner Spark One öfters das Problem, dass die EPG Daten nach einem Neustart oder über Nacht im Standby einfach verschwinden und ich wieder durch die einzelnen Kanäle zappen muss.

Woran kann das liegen bzw. wie kann man das Problem lösen? An fehlenden Speicher kann es ja eigentlich nicht liegen. Das RootFS hat noch von 109MB >50MB frei wenn ich mich recht entsinne und da DVB-C bei KD mit ~400 Sendern kann es ja eigentlich nicht zuviel werden.

Sollte ich evtl. das EPGRefresh Plugin installieren und über Nacht immer laufen lassen? Nimmt sich das Plugin nur die einzelnen Transponder vor (was ja ausreichend wäre) oder geht es jeden Sender einzeln durch?


Gruß

tecfreak

[16v]

Ich nutze das das Plugin.
Es geht jeden Sender durch, ABER:
entweder musst Du JEDEN Sender manuell hinzufügen, ODER das Bouquet.

[tecfreak]

Habs grad installiert und mach grad nen Testlauf. Ist es bei dir auch so, das bei den Farbtasten im OSD die Beschriftung fehlt?

[Kathi912]

Die Beschriftung sollte eigentlich da sein. Ist jedenfalls auf meiner 912 er so .nutze das Plugin schon lange und bin sehr zufrieden. Ich habe mir die passenden Sender raus gesucht die ich brauche. Läuft eigentlich sehr gut das Plugin. Gruss

[tecfreak]

Ne, Beschriftung fehlt bei mir. Das ist aber egal, denn man stellt es eh nur einmal ein. Hab mir jetzt eine Liste erstellt mit jeweils einem Sender für die einzelnen Transponder. Scan läuft noch, schaut aber bisher sehr gut aus.

Die epg.dat wird ja immer unter /media/hdd angelegt. Das ist doch der Flash-Speicher der Box (rootfs), oder nicht? Zumindest sagt mir "df -h" dass da nix anderes an der Stelle eingebunden ist.

[flac]

Kommt auf den Skin drauf an, ob die Beschriftung fehlt. Im Default Skin fehlt sie und wenn man in der Skin.xml
EPGRefresh herauskomentiert, ist das Standardfenster da und auch die Beschriftung.

Ich habe aber vor einiger Zeit, da ich einen selbstgemoddeten Default Skin benutzte, die Beschriftung manuel
in der Skin.xml eingefügt.

Gruß

Chris

- - - Aktualisiert - - -



Die epg.dat wird ja immer unter /media/hdd angelegt. Das ist doch der Flash-Speicher der Box (rootfs), oder nicht? Zumindest sagt mir "df -h" dass da nix anderes an der Stelle eingebunden ist.

Wenn keine Platte oder Stick dran hängt, dann wirds in der Box abgespeichert. Wo auch sonst?

[16v]

Bei mir passt alles.

/media/hd ist bei MIR die Festplatte...
die epg.dat liegt bei mir in etc/enigma2 - komme ja aus der anderen Ecke...

Steck Dir nen Stick in die Box, und schmeiß die epg.dat da drauf...

[SpaceRat]

Ob die EPG-Daten bei einem Neustart erhalten bleiben oder nicht entscheidet die Box nach Mondstand und Tageslaune.
Mal geht's, mal nicht.

Muß man anscheinend mit leben.
Ich hab auch das EPGRefresh Plugin und wenn die EPG-Daten weg sind, stoße ich per OpenWebif einen neuen Durchlauf an (Meistens starte ich die Box nämlich aus der Ferne neu, da ist das ein Aufwasch).

[tecfreak]

Ob die EPG-Daten bei einem Neustart erhalten bleiben oder nicht entscheidet die Box nach Mondstand und Tageslaune.
Mal geht's, mal nicht.
Ja aber woran liegt das? Kann doch nicht sein, dass die Daten einfach nach Lust und Laune gelöscht werden und ich nach dem Einschalten wieder kein Programm mehr habe. Das muss sich doch irgendwie beheben lassen. Wäre ja idF. mMn. ein dicker Bug.

@16v
Ist dieses Problem weg wenn man die epg.dat auf einen USB-Stick auslagert?

[flac]

Meine EPG Daten, die bei mir auf der SD Karte liegen und einmal am Tag von EPGRefresh regeneriert werden, sind immer da.

Gruß

Chris

[SpaceRat]

Ja aber woran liegt das? Kann doch nicht sein, dass die Daten einfach nach Lust und Laune gelöscht werden und ich nach dem Einschalten wieder kein Programm mehr habe. Das muss sich doch irgendwie beheben lassen.
Woran es liegt weiß ich nicht.

Meine erste Vermutung war mal, daß man schlichtweg so blöd war, das Beenden von E2 und das Vorbereiten des Linux zum Runterfahren unsynchronisiert parallel ablaufen zu lassen.
Damit hätte es passieren können, daß E2 erst dann zum Speichern des EPG kommt, wenn das Laufwerk schon ausgehangen (unmounted) ist.
Da Linux bzw. ext2/ext3/ext4 im Gegensatz zu Windows/NTFS auch keine echten Mountpoints, Junctions etc. ("file system reparse points") kennen, fällt sowas gar nicht weiter auf.

Das scheint aber nicht der Grund zu sein.
Mir ist später mal aufgefallen, daß E2 gerne im letzten Moment abschmiert, aus irgendwelchen Gründen wie z.B., daß es ein Handle nicht quitt wird u.ä.
Am Fernseher fällt es nicht auf, zu dem Zeitpunkt ist alles abgeblendet, das kann man nur sehen, wenn man auf dem Gerät mitloggt.

Insgesamt ist E2 voll mit blöden Fehlern wie potentiellen Null-Pointer-Refs, Division-by-Zero, Range-Verletzungen, usw. usf.
Das sind alles Fehlerarten, die nicht zwingend in der Praxis auftreten:
Wenn Du irgendwo in einem Programm x durch y teilst, funktioniert das ja ... solange y nicht 0 wird. Sicher ist das aber nur, wenn y erst gar nicht 0 werden kann.
Und wenn man ein Array aus 16 Bytes definiert, dann ist das kein Problem, solange man auch nur 16 Bytes reinschreibt. Kommt dann aber jemand auf die Idee, einen bis zu 16 Byte langen null-terminierten String dort abzulegen, dann kommt's zum Knall, sobald der String 16 Zeichen hat, denn da kommt ja dann noch \0 als Terminator dazu und wir sind bei 17 Bytes ...

Kompilier mal irgendein Linux-Prog, "0 warnings, 0 errors" kommt da nie raus.

Schaut man sich jetzt ein beliebiges git an, dann wird man feststellen, daß die contributors immer lieber irgendwelche neuen Features reinbauen oder an irgendwas verschlimmbessern, als diese Fehler zu jagen.
Ist auch klar, den "verschlüsselt/FTA"-Indikator in der Kanalliste sieht man ja, die 1000 verhinderten Green oder White Screens nimmt kein Benutzer zur Kenntnis.

Erschwerend kommt natürlich hinzu, daß die meisten Entwickler für irgendwelchen embedded-Kram wie E2 auch ansonsten Linux nutzen.
Jemand der tatsächlich Linux im Produktiveinsatz auf'm Desktop nutzt, denkt insgesamt nicht normal und hat auch kein normales Setup und damit keine normale Umgebung. Normalnutzer haben z.B. ein Netzwerk mit CIFS/Samba-Shares, bei Linux-Nutzern wird alles auf NFS gepresst, also treten bei den devs niemals Probleme mit CIFS/Samba auf :)

[santa]

Das Problem ist aber ganz einfach, wir sind jetzt schon am Ende unserer zeitlichen Möglichkeiten, somit sind oft nur dirty fixes möglich, auch wenn wir das alle gerne besser haben wollten.
Außerdem ist alles viel zu komplex, das komplett zu überschauen ist nicht möglich.

[SpaceRat]

Das Problem ist aber ganz einfach, wir sind jetzt schon am Ende unserer zeitlichen Möglichkeiten, somit sind oft nur dirty fixes möglich, auch wenn wir das alle gerne besser haben wollten.
Außerdem ist alles viel zu komplex, das komplett zu überschauen ist nicht möglich.
Das war kein Angriff gegen Euch.

Es bezog sich mehr auf Open Source Entwicklung allgemein und E2 insgesamt im speziellen und damit primär OpenPli.
Jetzt die Tage war das erste Mal, daß ich im OpenPLi-Forum merge requests für richtige Fixes gesehen habe.

Beim Programmieren ist es wie beim Hausbau auch:
Die ersten 95% gehen leicht von der Hand und machen Spaß, weil man was entstehen sieht.
Aber niemand macht gerne die letzten 5% Kleinarbeit, alles sauber abzuschließen.

Bei den letzten 5% ist der Aufwand in Relation zum sichtbaren Ergebnis immer mies:
Z.B. extra zum Farbenhändler gurken, um sich Silikon im RAL-Ton des Briefkastens mischen zu lassen, damit der UP montierte Briefkasten auch sauber abgedichtet wird.
Entweder bleibt's so oder man endet bei dem nächstbesten Silikon aus'm Baumarkt.

Bei Programmieren sind diese letzten 5% dann das sorgfältige Lesen von Tausenden Zeilen Programmcode, ggf. die Formatierung anpassen, nochmal für jede Funktion sorgfältig überdenken, was dort bei welchem Input rauskommt, usw. usf.
Ein Arsch voll Arbeit und sehen tut man davon nix ...

Ich bin da selber ja nicht anders, was ich für mich schreibe, das funktioniert bei mir zu meiner Zufriedenheit, bei anderen Leuten aber teils gar nicht.
Gebe ich den Kram dann raus, fangen die Kopfschmerzen an ... ich muß z.B. ständig berücksichtigen, daß selbst die banalsten Tools wie wget, unzip, zip, 7z bei den meisten anderen Leuten unter Windows nicht existieren, kein Perl-Interpreter installiert ist, nur die sch... CMD.EXE als Shell da ist und nicht Take Command/4NT, usw. usf.