EPG Database Backup Plugin for DreamOS

    Hi!


    Bei der Anpassung des XMLTV EPG Import Plugins an die EPG Datenbank im DreamOS haben wir auch diskutiert, ob es nicht Sinn machen würde ein Plugin zu haben das die epg.db wenn sie mal schön befüllt ist auch regelmässig Sichern und ggf Wiederherstellen kann.


    Ausserdem ist es eine Datenbank die man auch checken kann ob sie konsistent ist bevor man die Sicherung wiederherstellt.


    Das Try & Error ob es dumped mit einer alten epg.dat ist also NICHT mehr nötig.


    Ich habe das gewünschte halt mal in ein kleines Plugin gepackt und ich denke es ist selbsterklärend ...

    LG
    gutemine

    Ich habe noch eine 0.3 gemacht wo man statt dem restarten und händischen Löschen der epg.db um bei Problemen wieder einen konsistenten Stand zu bekommen im Plugin das erstellen einer leeren epg backup Datenbank anstossen kann und wenn man diese ladet sind ALLE EPG events weg und auch alle services sicher wieder OHNE Externe Quellen weil sie neu eingetragen werden.

    Kleines problem.


    Zitat

    Jan 04 00:24:51 dm7080 enigma2[176]: [EPGC] set outdated epg timespan to 0 hours...
    Jan 04 00:24:51 dm7080 enigma2[176]: [EPGC] set cache timespan to 14 days!
    Jan 04 00:24:51 dm7080 enigma2[176]: [EPGC] setCacheFile read/write epg data from/to '/etc/enigma2/epg.db_backup'
    Jan 04 00:24:51 dm7080 enigma2[176]: [EPGC] time updated.. start EPG Mainloop


    Irgend wie bleibt die falsche config.misc.epgcache_filename hinter im settings. Ich nach die backup in GP3 die stelle wo epg.db gespeichert geändert.

    wann passiert das, bei einem expliziten backup oder bei einem regelmässigen backup ?


    Weil eigentlich wird im Plugin nach 5 Sekunden nachdem die Backup Database gesichert oder geladen wurde der Parameter wieder zurückgesetzt. Du kannst es ausprobieren indem du dann enigma2 restartets und schaust wo dann die epg.db hingeschrieben wird.


    Und ich habe auch noch eine 0.4 gemacht wo ein sehr experimentelles Feature drinnen ist - nämlich in der Sicherung alle Externen Events als Interne zu markieren (indem die source_id von 5 auf 2 geändert wird). Bitte mit Vorsicht zu benutzen und zu testen wenn ihr so eine degradierte EPG Datenbank wieder ladet, da können komische Sachen passieren weil dann die externen Events mit über den SAT kommenden überschrieben werden sollten ... oder auch nicht ....


    LG
    gutemine

    Ich habe nur eine expliziten getestet und dann jeder Option aber nicht "empty". Alles sah gut aus aber die Anpassung mit GP3 ging es falsch. Es brauchte einige restarts bevor alles wieder gut ging.


    Ich behalte beim testen immer eine Kopie auf mein Computer.


    Die SD karte is jetzt auch gemountet wenn Enigma nicht aktiv ist...Enigma will nichts wissen vom die SD Karte so ich muss immer Umwegen benutzen.

    Danke. Habe es mal getestet und bis jetzt keine Probleme feststellen können. Mein Problem von gestern konnte ich komischerweise nicht mehr reproduzieren. Hätte mich ja mal interessiert ob mir EPGdbbackup hätte helfen können.

    Damit Ihr Euch nicht mit dem GP3 quälen musst habe ich auch die Möglichkeit den Speicherort der originalen epg.db zu ändern ins Plugin gemacht. Ausserdem altern die epg events in der Sicherungsdatenbank ja, daher gibt es jetzt auch die Möglichkeit events ausserhalb des EPG timespans aus der gesicherten Datenbank zu enfernen.


    Langsam wird ein kleines epg.db management tool draus, sollen wir es vielleicht auf EPGDBDoctor umbenennen ?


    Bitte also die 0.5 auch testen....


    PS: Soll ich evt. auch noch reinmachen das man einstellen kann das man die letzten X backups behalten will statt immer nur eines zu haben ?


    LG
    gutemine


    Eaglefire Ich denke die empty database Funktion hätte geholfen, aber Hautpsache jetzt geht es wie es sollte.

    Einmal Rupert und Zurück

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von gutemine ()

    Wirklich sinnvoll ist das aber auch nicht mehr ^^


    Ich habe erstmal eine 0.6 gemacht wo es erstmal als DB Option die Möglichkeit gibt alle extern geladenen Events wieder wegzuputzen, damit wieder DVB EPG Events geladen werden, das war wichtiger und ist sauberer als das Event degraden.

    Bekomme während des Betriebs v0.5 (jede Stunde folgenden Greenscreen)


    Die 0.8 hat jetzt wie versprochen die Möglichkeit einzustellen wie viele alte Backups (0-9) man zusätzlich zum aktuellen behalten will. Und die diversen Database Kommandos auf Blau ausführen kann man dann natürlich auch auf jede davon anwenden.


    LG
    gutemine

    Mit den heutigen Updates der DM7080HD crasht das Plugin beim ausführen oder Settings speichern

    Ich muss erst die nötigen Anpassungen machen damit das alles wieder sauber funktioniert, Wochenende hat doch erst angefangen ... wobei warum muss das eigentlich immer ich machen ... ist alles OpenSource, Ihr könnt Euch also theoretisch auch selber helfen ...

    Ich habe mal in einer 0.9 vom EPGdbBackup Plugin die load/save_finished events eingebaut die DMM uns spendiert hat.


    Bitte beachten das diese Version nur mit dem aktuellsten Enigma2 funktioniert.


    Wenn es hier im Plugin ohne crashen klappt dann mache ich die selben routinen am Wochenende auch ins EPGImport und ins OpenEPG rein.


    Also testet mal schön für manuelles Sichern und regelmässiges Sichern im Hintergrund wenn Ihr das überall in den epg.db Plugins haben wollt.


    LG
    gutemine

    I have used Epgbackup to test the vacuum function and that worked. Stopped enigma and restored my own backup because EPGBackup did not manage restore. However all is broken now and I can't get EPG working again and I can't find the place where epg.db is used. I have looked in /etc/enigma/ on my SD and on HDD.


    When running EPGimport XMLTV I get now the following error:

    I have removed EPGbackup now and after a lot of restart notting helps.


    Update: noting helps so I am going to reflash my box (7080) with back flashbackup from a few days ago.
    Update2: I have restored my backup of the flash and all is working again as before. :)

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von msatter () aus folgendem Grund: Restore image backup

    Well, but then you didn't understand how the Plugin works. Either you use it for backup and restore or not at all - but NOT backup and then restore something manually.


    The reason is quite simple - if you want to save somewehere outside of Flash the plugin temporary has to switch the epg db location settings parameter, save the epg.db there and then switch back to the original location. If you stop enigma2 in this process youare stuck with the temporary location as in your case.


    Anyway, choosing the default location in the plugin would have brought you back to business.


    Even a simple settings restore or as worst case when you don't have a settings backup a settings (=Factory) reset would have done also.


    Re-Flashing just to get a correct epg.bd location back was simply a waste of time and effort.


    Vaccuum is only done on the saved db - so correct approach is green so save, blue (with vaccuum) and then yellow to load - otherwise it will not change anything ....


    Which brings us back to understanding how Plugin works ^^


    And if you have a problem with EPGImport - post it in his Plugin thread.

    Yep, I did first a restore through the plug-in but that was the vacuumed epg.db so almost empty. The default location was not available and the plug-in only see the root directories of devices. The previous time I had also a problem with EPGbackup and that I just managed to fix it then.


    I put the crash-log of EPGImport in to show that the Enigma also did not knew anymore were it should go with dump of the epg.db or were to read it from. In settings, /etc/enigma2, was standing /media/sdcard as my defalut setting is /media/sdcard/XMLTVepg.


    The problem could be that I use also GP3 so there can be 2 captains on one dreambox ship that control the location of the epg.db.

    I don't actively support GP3 - if it works, great - if not ...


    BUT if you want to use EPGdbBackup you EITHER use the standard locations and epg.db name it supports (which ist /etc/enigma2 /media/hdd /media/cf /media/sd and /media/usb AND always epg.db als database name) OR it will not work, which is then for sure.


    And no, I will NOT change this, guess why the Plugin also offers ONLY these paths as original ones to change it within EPGdbBackup


    Any other locations or Names are NOT supported.

    To me it is strange that a program will overwrite the current epg path, if differs the STANDARD locations, in the enigma setting file and overwrite with its own without informing the user and give the option to abort the procedure and exit the the plug-in.

    The Plugin has to do it temporary to store the epg.db somewhere else. It proberly reverst this as soon it is finished with saving - unless your don't allow it to do it's job.


    If there would be a bug I would fix it - but as you don't gave any usefull input ... this is hard.


    PS: The crash in EPGImport.py is now hopefully fixed - thanks.

    Temporary store is no problem to me and that can be every were the plug-in has access to. It is surely not a bug because it was programmed that way.


    However you can discuss about that the plug-in ignores the current location of the epg.db file, allowed and used by Enigma. I can't test the fix in EPGImport.py because, I am afraid to have to restore my image if I create the same situation as yesterday morning.

    The Plugin has a setting to change the default location, and a setting to change the save location. If you use these it works as it should. If you don't use these you should not use the Plugin and ask others to implement all the epg.db Maintenance functionality. it offers.


    It is that easy ...


    If you would have used the EPGdbBackup Plugin to reset the default location to one it supports it would have worked as expected and all your panic actions including re.flashing would not have been needed. Removing/ignoring it and trying to manually recover is also possible with the measures I posted you (which you have not taken), but it is neither needed nor an efficient way to achive this goal.


    Finally the Plugin is OpenSource -. if your want it different - feel free to create your own/better version.


    gutemine

    I stopped enigma and started it to see were it would create the epg.db. I did not create any epg.db file on devices or in /etc/enigma2 so I stopped enigma again to edit directly the epg.db location in the settings file and started it again....still no epg.db. So I used EPGImport in the hope that would create an epg.db but the plug-in crashed and I put the log above.


    Reboots didn't help so I went back a few days old image backup, BTW created with help of an other plug-in created by you which I am using for ages now :) , and I only had to restore the epg.db from my local device and move on station to bouquet and I was back in business again.


    To me it is not logical to create all kind of branches of a programs. That is only confusing to future users that want to use it and see different versions of the same program. I will stay away from this plug because it just won't work for me.


    Keep up the good work and I will give input or help when ever I when I am able to.

    The EPGdbBackup Plugin has the possibility to create an empty epg.db - why you moved away to another Plugin which NEVER creates an empty epg.db is not logically to me.


    Nobody forces you to use my Plugin(s) but it you don't uset them correctly, make it worser with manual intervention and other Plugin not desinged for that purpose that you wanted to achive - WHAT do you think I should do?


    If you screwed up your epg.db you create a new one with the Plugin and set back the path and that's how it works - if you ignore this I simply cann't help except telling you what you did wrong.


    BTW EPGImport is NOT my Plugin (I only added epgd.bpy and had to fix some bugs to make it work) - in OpenEPG I already added a reset possibility on Yellow because you are not the only done doing nonsense and then panics 8)

    Your remarks in the Dream-Multimedia forum about speeding up the saving of the epg.db on shutdown did me look in the setting file. I did not find line "config.misc.epgcache_filename" which puzzled me. I do not use the default /etc/enigma2 for the location of the epg.db file so how does Enigma were to read and write it.


    After searching in the Blue forum I found the controlling setting in the gemini_plugin.conf file and the string there is "str=epgcachedir". This confirms my earlier assumption of two captains on one ship.


    When in both settings files a setting string is present then the location of the epg.db becomes unpredictable. I know a about the adaptation of the EPGImport and I was pleased that I could help you with testing it and supply some code in adapted version. ;)

    You are welcome but your 2 captains theorry is not really correct.


    There is ONLY 1 captain which is DMM and they clearly specify in mytest.py what the epg parameter should be:


    config.misc.epgcache_filename = ConfigText(default = resolveFilename(SCOPE_CONFIG, "epg.db"))


    Which means if there is no such line, then the above default config is used.


    EPGdbBackup follows and supports this, and only this setitngs approach including also the epg.db filename.


    If GP3.3 is re-inventing or tweaking whatever this is not my business and I will not spend any time on supproting this.


    Ciao
    gutemine

    Einmal Rupert und Zurück

    Dieser Beitrag wurde bereits 1 Mal editiert, zuletzt von gutemine ()

    Hi.


    nach dem akzuellem Update crasht die Box beim zurückspielen des EPG-Backups.
    Anbei der Crashlog

    Dateien

    Samsung - UE55 ES 8090


    Fritz!Box 7490 + Synology DS214play - 2x WD red 4tb


    DM7080HD RGB ssscc/t + DM525 combo <-- 28E;23E;19E;13E;KD

    das selbe auch beim speichern (nur als Feedback)


    DMM hat das angepasst damit das speichern schneller geht, ich habe aber erst in 1-2 Tage Zeit dafür mir das anzusehen, bis dahin müsst Ihr halt mit normalem EPG leben oder nicht upgraden.


    OoZooN hat auch nicht umsonst die aktuellen Sachen noch nicht auf seinem Feed weil das einfach Zeit braucht.


    Wobei alles OpenSource ist - wenn Ihr es eilig habt könnt Ihr Euch selbst und den anderen helfen ...

    gutemine schrieb:


    OoZooN hat auch nicht umsonst die aktuellen Sachen noch nicht auf seinem Feed weil das einfach Zeit braucht...



    ich hab grad ganz wenig zeit. ich weiss gar nicht, wo ich das zwischen quetschen soll. und bugs sind wohl auch noch drin, oder besser gesagt probleme mit anderen plugins ( änderungen am pts). ich glaub, vor sonntag schaffe ich das update nicht :(

    two beer or not two beer, that's the question!


    rotespony.jpg


    Mein kleines rotes Pony :love:

    Ich hoffe auch das bis zum WE DMM wenigstens die gröbsten Probleme fixed die sie da rausgeschoben haben, insodern macht warten durchaus Sinn - auch beim EPG Problem um das es hier konkret geht hat Reichi ja geantwortet das er das Problem identifizieren konnte.


    Nachdem es aber ziemlich sicher im C++ Code ist, muss ich jetzt halt warten bis ein neuer e2 tarbal rauskommt.


    EDIT: gerade auf Upgrade gedrückt ... also doch weiterspielen ...

    Einmal Rupert und Zurück

    Dieser Beitrag wurde bereits 2 Mal editiert, zuletzt von gutemine ()

    Seit heutigem Update kein Crash mehr

    Samsung - UE55 ES 8090


    Fritz!Box 7490 + Synology DS214play - 2x WD red 4tb


    DM7080HD RGB ssscc/t + DM525 combo <-- 28E;23E;19E;13E;KD

    Kann es sein, dass seit dem letzten DMM Update im dbBackup Plugin der Pfad zur Definition der EPG Backup-Datei nicht mehr einstellbar ist?
    es legt jetzt meine epg Backups immer unter /etc/enigma2 ab statt wie bisher /media/hdd/backups. Ich kann auch kein anderen Pfad mehr auswählen, während beim Orginalen EPG Pfad weiterhin /media/sd wo auch die epg.db liegt auswählbar ist.


    Gemini Plugin und auch epgcachedir steht epg auf /media/sd