Frage zur neuen EPG- Datenbank

    DDM8000 mit 2.0 und Crossepg 0.62 ist auf UK now/next andere long text als wenn ich single EPG benutze.


    Spater probiere ich es auf die DM7080.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

    NOCHMALS Vergleiche mit CrossEPG und OpenTV Daten sind nutzlos, die Beschreibungen sind da auch auf den alten Boxen nicht gleich

    2 Mal editiert, zuletzt von Lost in Translation ()

    @gutemine, hast du mich auf ignore? Ich schreib doch oben

    Zitat


    Auch wenn ich mir die Beschreibungen zukünftiger BBC-Sendungen im importierten EPG anschaue, sind sie ok. Und dann kommen sie nicht von now/next.


    Somit sind die Daten doch stimmig und ein Vergleich erübrigt sich.


    Sie werden beim DreamOS nur nicht richtig zur Aufnahme zugewiesen.


    Ich hatte gestern neben einer Autotimer-Top Gear-Aufnahme mit Vor- und Nachlauf parallel noch über EPG auf der selben dm7080 remote einen Timer ohne Vor- und Nachlauf programmiert. Vielleicht verhaspelt sich das System ja dabei.


    Ergebnis sehe ich morgen.

    Alptraumbox. :thumbs_up:

    Zitat von gutemine

    Könnt Ihr nicht mal wenigstens vorher die XMLTV FAQs und Wikis lesen .... BITTE ...


    Da gibt es reichlich Lesestoff bei unseren Holländischen Freunden, ich habe wenig Lust das abzutippen

    naja wäre ein einziger Satz gewesen, aber es funzt ja jetzt.
    Danke!


    Was mir auffiel, man muss nach jedem Lauf die Dreambox Neustarten, sonst werden keine weiteren Einträge in der EPG Liste angezeigt bzw. in die epg Datenbank ergänzt. Mit anderen Ländern/Files getestet

    In Betrieb
    Dreambox 920uhd-S2X/C
    Ausser Betrieb
    Dreambox 7080HD-S2/C / 8000-S2

    Vor einer Woche hat das damals aktuelle Plugin tadellos bei mir funktioniert und so wollte ich heute mal die neueste Version testen um meine EPG Daten zu vervollständigen. Nach mehrmaligen Versuchen (und auch Löschen der alten EPG Datei mit dem EPGBackup Plugin) bekomme ich einfach keine neue Daten mehr rein. Im Terminal spuckt das Plugin tausende der folgenden Zeilen aus:


    Code
    [EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'epoch_time'

    Ich kenne das Problem und teste eine wahrscheinliche Löschung fur das. Es kommt oft vor wenn die epg.db sehr groß ist ud wie groß war deine epg.db denn?


    OK ich habe einige test gemacht und die Warteschleife hilft echt und ich sehe so kein Performance Degeneration und die 'spinner' störren mich nicht.


    Code Suggestion:



    Code
    # is it really wise for the small performance gain ?
			if self.epgdb_size < 15000000:
  		       	        cmd="PRAGMA synchronous = OFF"
	                	self.cursor.execute(cmd)
 	                cmd="PRAGMA journal_mode = OFF"
	                self.cursor.execute(cmd)


    Die 15MB grenze und die wartezeit mussen noch 'gefinetuned' werden aber es hilft echt. Ich könnte nicht einlezen und mit die Anpassung geht es. Vielleicht ist nur die "time.sleep(3)" genugend aber das muss ich nog testen.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

    9 Mal editiert, zuletzt von msatter ()

    Das hat aber nichts mit EPGBackup zu tun das liegt auf Schwerkraft und wurde für OE2.2 deaktiviert.
    Also meinte er EPGdbBackup, woher soll ich das wissen. :face_with_tongue:

    Einmal editiert, zuletzt von dhwz ()

    Ja, ich meinte EPGDBBackup (den Namen könnte man noch optimieren, wie wär's mit XMLTVEPGDBBackup? :smiling_face: )


    msatter: du hast Recht, es scheint an einer zu großen DB zu liegen. Ich habe eben nur UK importiert und das hat geklappt (vorhin hab ich UK + F versucht).


    Erstaunlicherweise hatte ich aber auch schon Erfolg mit Import von UK+F+D+BeNeLux gleichzeitig (resultierte in einer 180 MB großen Datei!).

    Wir haben in den letzzten Versionen geändert das nicht bei jedem Laden ALLES zurückgesetzt wird sondern man selektiv laden kann, dann werden aber events auf Sender wo vorher geladen wurden nicht gelöscht und solange enigma2 solche findet werden auch keine über SAT/Kabel für diesen Sender geladen.


    Hier im Thread ist übrigens auch eine Version vom EPGBackup für OE2.2 gewesen, aber nachdem das keinen Sinn machte das komplett anzupassen und sich keiner gefunden hat der es tut habe ich eben das EPGdbBackup Plugin gemacht.


    Evt. werde ich es noch auf EPGdbManager umbenennen, weil es kann schon viel mehr als nur backup/restore, unnter anderem kann es eben auch die datenbank zurücksetzen (damit man sich das Löschen erspart) und eben auch die geladenen events wieder zu DVB events degradieren.


    Aber ich denke ich werde als Option ins EPGdbBackup auch wieder das Verhalten rein machen das früher das EPGImport hatte - sprich alle externen events aus der DB entferrnen um eben die DVB Events wieder zu ermöglichen. Das kann man dann benutzen wenn man es braucht.


    Und nein code mit sleep mache ich nicht ins Plugin, aber wenn das hilft lasse ich mir was Einfallen.


    LG
    gutemine

    Du machte den folgend vorschlag: normal müsste man das mit einem timer machen den du nach x sekunden nachsehen lässt ob es fertig ist.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

    Nochmals du sollst nicht mutwillig mit einem timer das enigma2 anhalten. Das ganze Problem kommt davon das du dir gewünscht hast das wir return nach dem os.path.exists rauszunehmen. Mit dem retry nach dem xmltv parsen hat das deutlich besser funktioniert, weil das fast immer ausgereicht hat das die epg.db in der zwischenzeit geschrieben wurde.

    hab mal mit journalctl -f -u enigma2 mitgeloggt, und folgenden Fehler am Ende bekommen

    In Betrieb
    Dreambox 920uhd-S2X/C
    Ausser Betrieb
    Dreambox 7080HD-S2/C / 8000-S2

    Ja das ist auch ein Fehler, die ganze Zeitberechnung gehört besser in den init Teil der routine, in einem try/except kann sie auch mal fehlen.


    Den Fehler das manchmal schon in eine alte epg.db geschrieben wird und deswegen das save vom enigma2 schiefgeht habt ihr auch noch nicht entdeckt.


    Ganz schön schwach Eure Testerei :smiling_face_with_sunglasses:


    Aber die CPU der box ist eh so leistungsfähig, ich lass den timer einfach mal ganz weg ... dann lebt es sich gleich unbeschwerter.

    Ich habe bei OoZooN im XMLTV EPG Importer Thread eine neue Version gepostet, wo die ganzen Fixes und Eure Inputs mal Q&D eingearbeitet sind - mal sehen ob das so stabiler ladet.


    Die kits hier habe ich entfernt, damit kein Durcheinander entsteht.

    6 Mal editiert, zuletzt von Lost in Translation ()

    Zitat von gutemine

    Den Fehler das manchmal schon in eine alte epg.db geschrieben wird und deswegen das save vom enigma2 schiefgeht habt ihr auch noch nicht entdeckt.


    Ganz schön schwach Eure Testerei :smiling_face_with_sunglasses:


    Meinst du diese Meldung?



    http://www.dream-multimedia-tv…&postID=141354#post141354


    Danke für die 2.1_r9 und ich werde die gut testen. :smiling_face:

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

    Wenn ich eine zweiten import mache bekomme ich im epgimport.py eine melding:



    update: wenn es nicht gut geht schriebt nach dem epg.db-journal enigma noch eine zweiten kleines epg.db-journal und ich sah eine große vom 633KB. Die zweiten wird direct wieder gelöst so ich kann nicht die exacte grosse erkennen.


    update:


    So nach des umbenennen/kopieren von epg.db-journal nach epg.db gibst zu wenig zeit um die Geister epg.db-journal wieder zu deleten und die import startet schon weil es noch in die Geister epg.db-journal geschrieben wird.


    Auch zwei variablen mussen dupliziert werden aus der 'try' nach den init Teil der routine.

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

    3 Mal editiert, zuletzt von msatter ()

    Seit einge stunden steh ein update für den box.


    4.2.1r10
    - fixed epgcache description search (e.g. fixes autotimer)
    - Wizard.py: re-add lost optional retval argument
    - fixed incomplete python stacktrace in crashlog files

    DM.One AIO, DM920, DM7080 archiviert DM8000 aus Dezember 2008 und eine DM600.

    Einmal editiert, zuletzt von msatter ()

    Danke fürs Ausprobieren. Dann bitte mit der r11 weitertesten, da wird auch auf das Schreiben des journals gewartet, bevor die gesicherte epg.db auch benutzt wird. Und die events counter sind jetzt auch in die init routine gemoved damit sie wenn sie im try/except nicht initialisiert werden, keine Folgexception verursachen.


    Ich denke wir sind damit jetzt auf dem richtigen Weg das Speichern der epg.db halbwegs sauber abzuwarten, trotzdem wäre es einfacher wenn DMM das call gleich synchron implementiert hätte, aber man kann nicht alles haben im Leben :face_with_rolling_eyes:


    Mit der r11 kann ich jetzt 3x hintereinander problemlos das Selbe EPG laden obwohl, die epg.db schon ganz schön gross ist und dadurch eben das Speichern dauert.


    Im Moment habe ich als Geduld für das Sichern im code mal 30 Sekunden reingemacht, bitte berichtet auch ob das bei epg.db > 100MB schon etwas knapp wird, dann würde ich es erhöhen, weil weh tun tut es nicht, wenn es früher fertig ist geht es ja eh früher weiter. Zu Lange sollte es aber auch nicht sein, das die Leute nicht zum Stromschalter greifen, weil sie glauben es hängt - also mehr als 60 Sekunden würde ich sowieso nicht reinmachen.


    Das Sichern vom recht grossen epg.db hat beim Runterfahren bei mir aber auch nie länger als 20 Sekunden gedauert, ich denke die 30 Sekunden sollten also ausreichen.


    Und schaut halt mal nach ob der fix der eingechecked wurde vielleicht auch bei den falsch gesicherten EPG Beschreibungen der Aufnahmen was hilft, wobei ich da wenig Hoffnung habe.


    LG
    gutemine

    Einmal editiert, zuletzt von Lost in Translation ()