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.
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.
NOCHMALS Vergleiche mit CrossEPG und OpenTV Daten sind nutzlos, die Beschreibungen sind da auch auf den alten Boxen nicht gleich
@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.
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
Hier mal ein Screenshot einer Sendung von ITV später am Abend. Passt soweit. Hab remote einen Timer mit Vor-/Nachlauf programmiert. Mal schauen, was dabei rauskommt.
Kann ja vielleicht doch mal einer mit CrossEPG vergleichen.
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:
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:
def start_process(self, epgdb_path=None, retry=False):
self.connection = None
epginstance = eEPGCache.getInstance()
eEPGCache.save(epginstance)
if epgdb_path is None:
epgdb_path=config.misc.epgcache_filename.value
epgdb_path_rollback = epgdb_path+"-journal"
self.epgdb_size = os.path.getsize(epgdb_path)
if not os.path.exists(epgdb_path):
# DMM has to fix that save is not synchronous
print "[EPGDB] %s not found and has been created" % epgdb_path
eEPGCache.load(epginstance)
# wait a while to time to write epg.db-journal
if self.epgdb_size > 15000000:
time.sleep(3)
for repeat in range (0,10):
if os.path.exists(epgdb_path_rollback):
print "[EPGDB] %s is still being written so lets wait" % epgdb_path_rollback
time.sleep(5)
Alles anzeigen
# 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.
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.
Ja, ich meinte EPGDBBackup (den Namen könnte man noch optimieren, wie wär's mit XMLTVEPGDBBackup? )
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.
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
ZitatAlles anzeigenJan 05 20:21:12 dm7080 enigma2[17481]: [EPGImport] ### thread is ready ### Events: 2885[quote]Jan 05 20:21:12 dm7080 enigma2[17481]: [EPGImport] Failure in epg_done
Jan 05 20:21:12 dm7080 enigma2[17481]: Traceback (most recent call last):
Jan 05 20:21:12 dm7080 enigma2[17481]: File "/usr/lib/enigma2/python/Plugins/Extensions/EPGImport/epgdata..._done
Jan 05 20:21:12 dm7080 enigma2[17481]: self.commitService()
Jan 05 20:21:12 dm7080 enigma2[17481]: File "/usr/lib/enigma2/python/Plugins/Extensions/EPGImport/epgdata...rvice
Jan 05 20:21:12 dm7080 enigma2[17481]: self.epg.preprocess_events_channel(self.services)
Jan 05 20:21:12 dm7080 enigma2[17481]: File "/usr/lib/enigma2/python/Plugins/Extensions/EPGImport/epgdb.p...annel
Jan 05 20:21:12 dm7080 enigma2[17481]: if self.end_time > self.epoch_time and self.begin_time < self.epg_...time:
Jan 05 20:21:12 dm7080 enigma2[17481]: AttributeError: epgdb_class instance has no attribute 'epoch_time'
Jan 05 20:21:12 dm7080 enigma2[17481]: [EPGImport] imported 2885 events
Jan 05 20:21:12 dm7080 enigma2[17481]: accel 11872 bytes
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memstat: used=40320 kB, free 90752 kB, s 40320 kB
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memory: 0
Jan 05 20:21:12 dm7080 enigma2[17481]: accel 11872 bytes
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memstat: used=40332 kB, free 90740 kB, s 40332 kB
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memory: 0
Jan 05 20:21:12 dm7080 enigma2[17481]: accel 11872 bytes
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memstat: used=40344 kB, free 90728 kB, s 40344 kB
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memory: 0
Jan 05 20:21:12 dm7080 enigma2[17481]: create buffer for widget 810 x 179
Jan 05 20:21:12 dm7080 enigma2[17481]: accel 581392 bytes
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memstat: used=40356 kB, free 90716 kB, s 40356 kB
Jan 05 20:21:12 dm7080 enigma2[17481]: accel memory: 0
Jan 05 20:21:12 dm7080 enigma2[17481]: [EPGImport] #### Finished ####
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
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.
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
Meinst du diese Meldung?
ZitatAlles anzeigenBeim "saven" geht auch was falsch im Enigma:
Dec 27 16:51:49 dm7080 enigma2[170]: [EPGC] 10e0 0418 0001 00c00000 has external data! won't update...
Dec 27 16:51:53 dm7080 enigma2[170]: [EPGImport] autostart (1) occured at 1419695513.77
Dec 27 16:51:53 dm7080 enigma2[170]: [EPGImport] Stop
Dec 27 16:51:54 dm7080 enigma2[170]: [EPGC] remove channel 0x32c3348
Dec 27 16:51:54 dm7080 enigma2[170]: [EPGC] abort caching events !!
Dec 27 16:51:54 dm7080 enigma2[170]: [EPGC] db thread stopped
Dec 27 16:51:54 dm7080 enigma2[170]: [EPGC] data thread finished
Dec 27 16:51:54 dm7080 enigma2[170]: [EPGC] Saving database from memory
Dec 27 16:52:40 dm7080 enigma2[170]: [EPGC] Saving failed! Your EPG data will be lost! SORRY!
http://www.dream-multimedia-tv…&postID=141354#post141354
Danke für die 2.1_r9 und ich werde die gut testen.
Wenn ich eine zweiten import mache bekomme ich im epgimport.py eine melding:
ZitatAlles anzeigen[EPGImport] afterDownload /tmp/epgimport.gz
[EPGImport] Using twisted thread!
[EPGImport] unlink[XMLTVConverter] Enumerating event information /tmp/epgimport.gz
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
.
.
.
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
It's now [EPGImport] ### importEvents exception: Mon Jan 5 23:05:25 2015database is locked
[timer.py] next activation: 1420495625 (in 99995 ms)
It's now [EPGImport] ### importEvents exception:Mon Jan 5 23:05:25 2015
[timer.py] next activation: 1420495625 (in 99992 ms)
database is locked
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
.
.
.
[EPGImport] ### importEvents exception: database is locked
[EPGImport] ### importEvents exception: database is locked
before: 1
after: 1
[EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'events_in_past_journal'
[EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'events_in_past_journal'
[EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'events_in_past_journal'
[EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'events_in_past_journal'
[EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'events_in_past_journal'
[EPGImport] ### importEvents exception: epgdb_class instance has no attribute 'events_in_past_journal'
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.
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
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
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