Ghost

Es gibt eh schon rechlich EPG Events auf die man subscriben könnte, da kähme es auf einen start/end save/load auch nicht mehr an

Das man nicht einfach synchrone Sachen ins enigma2 machen sollte verstehe ich auch, nur in dem Fall bräuchte ich es halt synchron, weil bevor das Sichern fertig ist mach es einfach keinen Sinn was mit der epg.db anzufangen.

Eigentlich weckt das load/save beim EPG einfach falsche Erwartungshaltungen weil es eigentlich ein startLoad und ein startSave ist

Intern müsst Ihr ja sowieso eine Flag im code haben wo gespeichert wird ob gerade ein load/save läuft, und in der enigma.py gibt es eh schon ein chacheState, könnte man das nicht auch in eine routine wrappen die dann halt 0 (memory) 1 (loading) 2 (saving) zurückliefert bis es fertig ist ?

Dann kann sich jeder selber Abfrage und Timer bauen, um zu überprüfen ob load/save fertig ist und wir brauchen nicht unbedingt noch einen Event/messagehandler einbinden ?

Oder wenn das load/save async bleiben dann würde auch sowas wie das was ich als Workaround als isSaving gestricked habe reichen - also ein eEPGCache.busy (mit optionalem timeout=30) das solange nicht zurück kommt wie eben noch ein load/save läuft. Dann kann man das load/save async starten und sync aufs Ende warten - falls man möchte. oder es braucht und sonst bliebe es async wie es ist.

Letztendlich müssen wir aber sowieso nehmen was wir kriegen, aber irgend eine Möglichkeit das sauber zu lösen wäre schon sehr nett.
Jetzt ist es halt unsauber, weil wenn ich die Datenbank connecte während sie noch oder eben erst geschrieben wird, dann passieren die komischen Geisterjournals, oder das save geht schief, etc. und das ist noch unbefriedigender und macht die Sache recht mühsam.

LG
gutemine

msatter

Das haben wir doch schon diskutiert, wenn das enigma2 externe events irgnoriert auch beim Housekeeping, dann brauche wir ein eigenes Housekeeping was die alten Sachen rauslöscht, du kannst nicht davon ausgehen das jeden Tag oder hintereinander das Gleiche immer wieder geladen wird, wenn du also EPG Daten für DE geladen hast und dich dann entscheidest nur mehr UK zu laden, dann werden wenigstens morgen (oder wenn das keep old vorbei ist) alle gestern geladenen DE externen EPG events gelöscht und damit in Folge wieder die Daten vom Transponder genommen. Und deswegen auch das Housekeeping nach dem change date und nicht nach begin Zeit, weil sonst müsstest du bis zu 28 Tage warten bis der Eisberg an geladenen EPG Daten von alleine abschmilzt, weil nur immer abgelaufene tage gelöscht würden. Das change date ist also besser, auch wenn man dann das selbe gleich wieder ladet. Aber es können auch Sendungsänderungen zu gestern passiert sein, insofern macht das schon auch da Sinn. Ich werde bis Ghost uns was schönes baut halt die saving routine noch cleverer machen, das handling der journal files habe ich ja gestern erst sehr spät eingebaut, das ist sicher nicht perfekt.

EDIT: Ich habe eine r12 gemacht wo das checking ob noch geschrieben wird über die modification time läuft, sprich wenn seit 5 Sekunden nichts mehr geschrieben wurden, kein journal mehr da ist und die size der epg.db > 23k ist - dann ist sturmfreie Bude

Keine weiteren Problemberichte mehr zur 2.1-r12

Dann würde ich die saving routine im epgb.py die das Warten bis das Speichern der epg.db abgeschlossen ist sicherstellt erstmals so lassen und warten was wir von DMM bekommen um das etwas weniger holprig zu lösen.

PS: Die selbe routine ist jetzt übrigens auch in der letzten Version vom EPGdbBackup Plugin drinnen.

LG
gutemine

Danke, besondern nett wäre wenn du auch das EPGdbBackup kurz beschreiben würdest, weil das kann in der Zwischnezeit auch eigentlich fast alles was man so rund um die epg.db brauchen kann, nicht nur sichern und wiederherstellen

Da ist nicht viel zu lesen, ist eigentlich selbsterklärend du kannst entweder regelässig die epg.db sichern oder explizit auf Grün und Laden geht explizit auf gelb.

Nur die ganzen DB Befehle auf blau muss man ... ausprobieren ...

die r11 hatte aber ein problem mit recht grossen epg.db, die r12 sollte damit besser umegehen können ... hoffentlich ... aber das findet Ihr schon raus ...

Ich habe es gesehen, aber ich muss es mir erst ansehen wie man das verwendet und den code vom epgdb.py dann entsprechend anpassen damit das EPGImport und OpenEPG Plugin damit auch richtig funktionieren.

Aber Wochenende hat auch erst angefangen ... und ein bisschen Input wie man es verwendet wäre auch nicht schlecht

Ich komme gar nicht soweit, weil scheinbar hat DMM da was kaputt gemacht, nicht mal ein simples

self.epginstance = eEPGCache.getInstance()
eEPGCache.load(self.epginstance)

einer vorher durch einen enigma2 restart auf /etc/enigma2/epg.db rausgeschriebenen EPG Datenbank geht mehr ohne das es crashed:

[EPGC] db thread stopped
thread joined 0
[EPGC] Loading database into memory
before: 1
after: 1
[EPGC] db thread started
[EPGC] start caching events(1421494127)
PC: 0053a980
 00000000 00000001 00000000 00000155
 6367ed10 0000000d 00000000 00000000
 00000001 00000000 62b00010 ffffffff
 00000000 2037312d 323a3131 00950000
 011f5958 011dc570 62d22128 011dc578
 011f4ea8 62d00b38 00000001 011f595c
 00956b30 748b1dc0 00000000 00000000
 748d7020 6367ecb8 6367ee00 00548a94
As a final action, i will try to dump a bit of code.
I just hope that this won't crash.
0053a980: 58 00 c3 8c 5c 00 c2 8c 54 00 c8 8c 38 00 b1 af 34 00 b0 af 3c 00 bf af 21 80 80 00 00 00 85 ac (end)
-------
thread joined 0
ERROR reading PES (fd=68) - Value too large for defined data type

beim sichern passiert das gleiche

Danke, aber kein Stress ich komme eh erst Abends wieder zum basteln und ausser mir verwendet das leider eh keiner

Zur "Strafe" würde ich mich dann aber auch über ein paar Zeile freuen wie man das chachestate verwenden soll