wie du richtig erkannt hast kann man eigentlich nur gleichen Befüllungsstand vergleichen, ich habe nicht umsonst auf Gelb eingebaut das man sich wieder eine leere epg.db machen kann.

Und soweiit ich damit testen konnte ist der Unterschied jetzt minimal, weil die dvb event id ja jetzt nur mehr berechnet wird indem ich die Minuten des epoch time bestimme die über der durch 65536x60 teilbaren Teil der Zahl sind (damit der wert immer < 65536 ist):

self.dvb_event_id=(self.begin_time-(self.begin_time/3932160)*3932160)/60

Wenn jemand einen besseren/schnelleren Weg hat das zu berechnen, evt. mit einer der vielen python Funktionen wie compile .. her damit.

Oder Ghost macht und ein genDVBEventID wo man begin Zeit, Titel und description reinkippt in C++ das man vom Python aus verwenden kann. Aber wie schon gesagt, es geht auch nur mit der Begin Zeit durchaus stabil zu lösen, weil es ja nur pro Sender unique sein muss und die wenigen Beginnzeitverschiebungen sind nicht wirklich das Problem denke ich mal wenn dann nur ab und an mal eine Aufnahmedescription nicht stimmt.

Weil wie schon gesagt wenn dadurch das Problem mit der dvb event id gefixed ist dann ist es nur mehr eine Frage der Performance.

Was mich eher amüsiert ist das wenn es wirklich so ist wie Ghost sagt das auch die alten enigma2 davon betroffen sind, dann ist das schon der 3.Bug bzw. blödsinnige Code den wir hier im EPGImporter unserer holländischen Freuden gefunden haben. Die merken das nur nicht mehr weil sie schon lange das importEvent mit dem enisprechenden enigma2 patches benutzen statt ins epg.dat zu schreiben wo der bug besteht.

Also fixe ich das auch sicher nicht weil die epgdat.py eh schon lange nicht mehr zu funktionieren scheint was darauf hindeutet das es Ihnen egal ist wenn die epg.dat nur mehr zu crashes führt. Deswegen funktioniert das XMLTV ja auch nicht mehr mit OE2.0 Images und CrossEPG der seinen eigenen code zum epg.dat schreiben benutzt ist so populär geworden weil es die einzige funktionierende Alternative war und ist.

dann brauch ich ein enigma2 log ... da steht dann warum es nicht ladet ...

Und für Idel sollte es egal sein (dann geht Zappen natürlich nicht), Laden aus dem Standby ist der interessante Teil der Frage.

Mir ist das sowieso ziemlich egal, aber wenn es schon mal schneller war weckt das halt Begehrlichkeiten.

Und rechnen in python ist halt nicht gerade das flotteste ... da kann man schon noch an der Performance schrauben.

Selbst der sql code ist noch nicht ausgereizt und der ist immer noch der echte Bremser hier, sonst wäre es ohne epg.db nicht doppelt so schnell auf der 7080.

Und bei mir ladet gerade EPG während die box idle ist. Schau mal ob du beim testen die epg.db kaputt gemacht hast. Checken mit EPGdbBackup ist ja keine Hexerei oder dann wieder leere epg.db anlegen.

Weil ich glaube nicht das sich da zwischen r7 und r11 geändert hat, da habe ich NUR an der dvb event id was geändert.

Kann schon sein weil das ist ein simpler Timer Thread und wenn man die Einstellungen saved wird der nicht gestopped und neu gestartet sondern nur bei enigma2 restart - wenn man vom Standby ladet ist das egal weil er beim booten mit der aktuellen Lsdezeit startet. Bei Idle kann es sein das er dann nicht zur richtigen zeit aufwacht ohne restart.

Das auch noch einzubauen macht aber nur begrenzt Sinn, weil man ausser beim Testen die Zeit eh nur 1x einstellt und es dann jeden Tag zur selben Zeit laufen soll denke ich mal.

Nicht böse sein, aber langsam muss ich den Aufwand der in das epg zeugs reinläiuft begrenzen, das ist sowieso schon ausgeartet, dafür das ich hier nur aushelfen wollte

wie schon gesagt, ich habe schon zu viel dran geschraubt, für den Brot und Butter Kunden der einfach nur sein Britisches EPG Laden will reicht das längst aus. Fehler wie das mit der dvb event id oder dem Crahs im EPGImport Plugin müssen halt gefixed werden, aber den Rest an Verhübschnungen und Erweiterungen könnte wer anderer genauso machen.

Vor allem bleiben bei mir dann andere Sachen liegen wovon wir alle wahrscheinlich mehr profitieren würden. Im Prinzip muss ich ja genauso erst Sachen ausprobieren und herumspielen bevor was hablwegs sinnvolles raus kommt - was erstens Zeit aber zweitens auch Motivation braucht es zusammen zu bringen. Bei der epg.db ist die Motivation längst weg, weil das was mich interessiert hat ist längst erledigt.

Insofern wird es im Laufe des Wochenendes auch beim OpenEPG eine 1.2 geben und mit der müsst Ihr dann erstmal zurecht kommen oder sie Euch selber anpassen.

Ja Leute die Du und bschaar die sich mit mir gequält haben um überhaupt so weit zu kommen haben ja auch ein Anrecht feedback zu geben und sofern möglich habe ich auch versucht Eure Wünsche umzusetzen. Schau dir aber an wie lange der Thread ist, welche hitrates er hat und Goodle ein bisschen wo überall du die entstandenen Plugins runterladen kannst. Dann wird dir rasch klar warum ich das nicht OK finde wenn wir uns hier alleine abquälen und das ganze damit unnötig viel von meiner und Eurer zeit frisst.

Vielleicht bin ich etwas altmodisch, aber die hier implementierte Funktionalität wäre auch in 2 Wochen fertig zu stellen gewesen statt der 2 Monate, aber dann eben auch gemeinsam und nicht einsam.

Nicht umsonst habe ich eine Vielzahl von Plugins (inklusive dem ganzen OE 2.0 Zeug) über Board werfen müssen um überhaupt noch was sinnvolles für Euch machen zu können.

Also nicht böse sein wenn ich auch mal sinnvolle Endpunkte setze oder bei manchen Sachen einfach verweigere oder Nein sage.

All die Sachen die wir hier gemacht haben sind 100% quelloffen und können von jedem von Euch weiter entwicvklelt und an die Bedürfnisse der user angepasst werden, Ich habe mich sogar bemüht dinge zu dokumentieren oder hier zu beschreiben wie es geht, und auch DMM hat geholfen soweit das möglich und sinnvoll war, aber letztendlich ist das auch vergebens wenn dann nichts passiert und statt dessen ich mich weiter damit herumschlagen muss.

Dann hilft nur mehr die Kaltwasser Methode

Damit Ihr seht was ich meine, das ich lieber was innovatives mache um echte Probleme zu lösen statt ewig an Sachen herumzuschrauben die auch wer anderer machen kann:

Stört es euch eigentlich dass das Abspeichern der epg.db beim Runterfahren so lange dauert wenn sie durch die EPG Ladeplugins eine 'ordentliche' Größe erreicht hat ?

Sollte man dagegen nicht endlich was unternehmen ?

Testen wir einfach mal ob einer von Euch eine Idee hat ... die auch funktioniert ... also die 20 Sekunden die das epg.db Sichern beim Runterfahren dauern kann auf 1 Sekunde runter bringt.

Ich habe darüber schon vor 3 Wochen nachgedacht und auch eine der möglichen Lösungen ausprobiert, aber Ihr lasst mir ja keine Zeit um das als Plugin zu implementieren

Wäre es nicht sinnvoller wenn ich meine Zeit damit verbringen würde?

Würdet Ihr nicht lieber sowas testen ?

Wäre doch besser als zu jammern, oder ?

PS: Warum DMM das nicht so gelöst hat ist eine andere Frage, weil in C++ wären das 2 Codezeilen mehr im enigma2 binary (was auch einer der Gründe war warum ich noch kein Plugin draus gemacht habe) - aber jetzt schauen wir mal was für Ideen Ihr so habt

Sorry, Ihr denkt schon wieder zu kompliziert

Wenn die Box in 20 Sekunden bootet und dann 40 Sekunden braucht um runter zu fahren dann führt das schon zu hochgezogenen Augenbrauen und die Leute fangen an eure epg.db Lösung unnötig schlecht zu reden.

Und ja natürlich kann ich es auch einfach verraten wie einfach das geht statt euch zappeln zu lassen:

Macht mal folgende Zeile in die /etc/enigma2/settings bei gestopptem enigma2:

config.misc.epgcache_filename=/dev/shm/epg.db

Dann startest du enigma2, und dann lässt du mal EPG Refresh für die Deutschen Sender laufen und ladest noch mit OpenEPG alles von UK dazu.

Dann machst du einen enigma2 restart und wunderst dich das die 40MB in 1 Sekunde auf das tempfs geschrieben wurden.

OK, bevor es dann heisst aber das ist ein tempfs, wenn ich die box runterfahre ist es dann ja weg, dann machst du ein cp /dev/shm/epg.db /etc/enigma2/epg.db und merkst das das auch in 1-2 Sekunden fertig ist weil jetzt auf einmal nur 1 großes file kontinuierlich geschrieben wird.

Und dann weist du was die 2 Codezeilen im enigma2 sind in der EPG save routine um das endlich performant und 10x so schnell wie derzeit zu lösen

Und es ist ja nicht nur das runterfahren, bei jedem enigma2 restart hast du das selbe Problem dass er unnötig lange dauert durch das epg abspeichern.

PS: Ich hatte das schon damals im Hinterkopf als ich gefragt habe ob man das save der epg db nicht einfach synchron machen könnte, dann muss es halt auch entsprechend flott fertig sein.

PPS: Und wenn ich /dev/shm als location beim Laden des EPG benutze ist es auch etwa 20% flotter, schon weil ich da die epg.db ja auch unmitelbar nach dem Laden wieder hochlade ist es ziemlich egal wo sie sich befindent - wenn Ihr also nett seit löscht Ihr die temporäre epg.db auf /dev/shm bitte nicht nach dem kopieren auf den echten Platz. Memory haben wir ja genug in den Boxen.