First /dev/shm and /tmp with tmpfs will not behave the same - try to change the location to /tmp/epg.db and you will find out the difference yourself.

Second there is no real need to make tempfs persistent or whatsoever, the trick is just to make the dumping memory database code that DMM uses faster by using a filesystem without any write resistance and then copy the file in bulk from there. enigma2 already has a very effiicient and fast file copy routine in the C++ part, you just need to run the epg save to /dev/shm and then copy from there, there is no need for any cp or rsync as your link suggests.

I could write a small plugin as PoC but if you try it out manually as explained in my previous post it is already more then obvious that and how easy the current save mechanism could be improved.

Hence I'm now simply ... waiting

die epg.db läuft sowieso im Memory, genauso wie die timers, die settings... also hat das enigma2 binary sowieso code um sie beim runterfahren rauszuschreiben.

Die epg.db ist auf Grund der möglichen Größe und weil zuerst das journal und dann erst die database geschrieben wird aber eben ein Sonderfall, die save routine im enigma2 aber so anzupassen das zuerst in /dev/shm gesichert und dann erst von dort in einem Aufwasch auf die richtige epg location gesichert wird sind aber eben nur genau die 2 codezeilen, und schon ist es wesentlich flotter und das Ergebnis das gleiche.

Im Prinzip ist mir ja egal ob und wie DMM das macht, aber wenn es eben deutlich performanter ginge und das mit minimalstem coding Aufwand, dann darf ich doch dezent darauf hinweisen?

Natürlich kann ich mir ein Plugin machen das den save parameter auf /dev/shm verdreht und dann beim booten schnell noch vor dem enigma2 restart aus /etc/enigma2 die epg.db dorthin kopiert oder damit es keine bootzeit kostet einen simplen symlink macht und den dann wieder löscht und halt beim runterfahren noch schnell das copy reledigt - aber wozu soll ich mir die Arbeit machen?

Manchmal muss man nur beweisen das man nicht unbedingt um Afrika herum shippern muss, um nach Indien zu kommen, weil wer bereits vor fast 150 Jahren den Sueskanal gebaut hat

Nachdem keine Fehlermeldungen mehr kommen oder Vorschläge wie man den code noch performanter machen könnte, gehe ich mal davon aus, dass das Problem mit der dvb ebent id jetzt ausreichend gelöst ist.

Ich lasse die kits also erstmal so wie sie sind ... und wir warten...

Danke fürs Feedback - was nimmst du eigentlich so von UK überlicherweise auf ?

Noch ist das Wochenende auch noch nicht um, aber ich würde aus aktuellem Anlass am Abend gerne was anderes machen.

Bei BBC & Co verstehe ich das schon, aber der Rest (die paar True* und CBS*) die FTA sind und auch weiter im Osten zu empfangen rentieren sich für mich nicht withklich.

Nicht umsonst sagte ich das ich das ganze EPG Zeugs selber nicht wirklich brauche.

Schade nur das es keinen Hack gibt um die Deutschen EPD Daten vom Transponder von TVTV direkt auszulesen (weil der ist für länger verfügbar als das was die Sendeanstalten ausstrahlen), aber sowas zu machen wäre auch nicht sehr klug weil es Receiverhersteller gibt die dafür gutes Geld bezahlen und die wären dann 'not amused'

Danke dann scheint die dvb event it mit der Anfangsminute ja zu funktionieren.

Viel mehr kann ich dann im Moment eh nicht tun, weil wie schon gesagt das epg save zu beschleunigen und damit ggf. auch die events in eine /dev/shm/epg.db zu laden, damit es noch flotter geht, das muss sich DMM überlegen, ob sie es einbauen und vorher mache ich sicher nichts in die Richtung, weil ich mag das nicht 2x implementieren.

es steht dir frei die Harddisk bereits vom enigma2 umounten zu lassen und nicht aufs Linux zu warten, aber das ist hier OT.

Und ich habe da gar nichts 'gefunden' ... nur ausprobiert was funktionieren könnte ...

Jetzt warten wir mal ...

Nur um entsprechende Fragen zum XMLTVImporter für DreamOS zu vermeiden - auch hier was im Thread bei OoZooN steht:

Ihr werdet auch ein *sources.xml auf /etc/epgimport benötigen, aber da ein Forum Moderator und
PLi® Core member seine Bandbreite für nicht-Dreamboxen schonen will,
habe ich entschieden das *deb zu entfernen wo es drinnen ist - helft Euch also selbst.

You will also need a *sources.xml at /etc/epgimport, but as a Forum Moderator and PLi® Core member wants to save his bandwith for non-Dreamboxes, I decided to remove the *.deb containing it - therefore help yourself.

Kein Kommentar - es kann sich jeder selber sein Bild machen.

Aber ich sagte nicht umsonst schon am Anfang des Threads das da wenig an Support zu erwarten ist und ich auch deswegen das eigentliche Plugin tunlichst nicht antasten will.

Ich habe jetzt eine Version 2.3 vom XMLTV Plugin gemacht die auf den aktuellen Sourcen unserer holländischen *** basiert.

Bitte testet und berichtet, ob damit im DreamOS wieder alles wie gewohnt funktioniert.

Nachdem ich für die Anpassungen im XMLTV Plugin damit es mit den
aktuellen Sourcen funktioniert auch Kleinigkeiten in der epgdb.py ändern
musste, habe ich diese auch ins OpenEPG Plugin übernommen und eine r12
davon gemacht.

LG

gutemine

sehr brav

Bei degrade wird die Pirority von 99 wieder auf 0 reduziert. das macht sinn wenn man die geladenen Events erhalten will (weil man z.B. schon timer drauf hat oder ähnliches) aber in Zukunft für den Sender keine Externen EPGs mehr laden will, dann schmilzt der Eisberg der geladenen EPG daten langsam ab und es werden die ausgestrahlten EPG daten drüber geschrieben. Sonst würden solange man externe events für den sender hat der ausgestrahlte EPG nie verwendet und man müsste bis zu ein Monat warten bis alles geladene weg ist.

Und man kann es auch verwenden um zu testen ob man geladene und ausgestrahlte events mischen kann

Den Rest schaue ich mir unter der Woche gerne an und gebe Feedback, aber lesen können auch andere und sagen ob sie es verstehen.