Da du explizit OpenATV erwähntest, zielte die Frage nur darauf, ob die IPKs auch auf DMM-Images laufen.
Testen wollte ich ohnehin selber.
Wäre deine Antwort jedoch gewesen, ja, läuft nur auf OpenATV, hätte ich mir das Testen sparen können. 
Aber so schaue ich mir das mal an. 
Gerne, weil um ehrlich zu sein daran habe ich gar nicht gedacht, für mich ist OE 2.0 schon Geschichte.
Im OpenATV habe ich ja nur getestet weil ich die Performance auf der selben Box mit dem epg.dat code gebraucht habe.
Ich sage einfach mal:
Frohes Neues Jahr und ein dickes
DANKE!
Ich muss mich auch bedanken, vor allen bei den wenigen 
die mitgeholfen haben das es rechtzeitig zum Neuen Jahr mehr oder weniger fertig geworden ist.
Mir hat das mit dem Performance Unterschied zur epg.dat keine Ruhe gelassen. Man sieht ja das die CPU auf 100% anschlägt und das heisst es muss etwas viel CPU kostemn bei den Inserts.
Ich denke ich weis jetzt woran das liegt - die epg.db benutzt ja indexes um beim suchen flott zu sein, wenn du die während einem Massenload aber aktiv hast sortiert sich die Box zu Tode. Löscht man sie vor dem Insert und legt sie nachher wieder an wird nur einmal sortiert und das Ganze ist sofort um 20-30% flotter.
Wer es nicht gaubt soll die r3 im Anhang probieren 
Diese Variante kann rund 25.000 Events pro Minute verarbeiten und die box bleibt so agil wie gewohnt.
Also DE/AT/CH + UK EPG =125k Events sind in 5 Minuten geladen ... ich denke das kann man so lassen
Auch wenn die epg.dat Variante trotzdem nur 2min braucht 
LG
gutemine
Wow nicht schlecht. Das geht wirklich viel viel schneller.
Ja Indexes sind was Feines, allerdings nicht wenn man sie ständig aktualisieren muss
Und 25k Events pro Minute sind nicht so schlecht, dafür das eine Datenbank drunter ist.
Wenn man die Trigger auch noch temporär rausnehmen würde, dann wäre es wahrscheinlich noch flotter, aber irgendwann muss auch Schluss sein, das könnt ihr selber ausprobieren. Ich kann mit der derzeitigen Performance auf jeden Fall schon leben, ist immer noch flotter wie auf der 500hd.
Mit .schema kann man im sqllite3 ja leicht die Befehle zum trigger wieder anlegen klauen, mit den indexes habe ich es für die r3 ja genauso gemacht.
Eine Wunsch vom mir ist um von 'External Data' (99) nach 'Internal Data' (0) zu gehen so dass EPGC auch die cache events kann aktualisieren in die vom XMLTV geladene EPG events.
Im EPGImport.py Bigstorage umgehen und nur '/tmp' benutzen um der ort wo die XMLTV bestanden geschrieben werden. Spart die zeit die das anlaufen der Harddisk aus.
def do_download(self,sourcefile):
path = '/tmp'
filename = os.path.join(path, 'epgimport')
if sourcefile.endswith('.gz'):
filename += '.gz'
sourcefile = sourcefile.encode('utf-8')
print>>log, "[EPGImport] Downloading: " + sourcefile + " to local path: " + filename
downloadPage(sourcefile, filename).addCallbacks(self.afterDownload, self.downloadFail, callbackArgs=(filename,True))
return filename'Indexing' muss ich mich noch ansehen und auf meinen plus 100 MB EPG habe ich es abgebrochen weil es sehr lange dauerte.
Ich muss auch ausfinden warum die epg.db immer mit 162KB zunimmt ob woll es keine neue Daten sind beim einlesen.
schau dir die diversen Pragma Einstellungen an, da kannst du die Page size mit der rausgeschrieben wird anpassen und dein autovacuum gäbe es auch.
http://www.tutorialspoint.com/sqlite/sqlite_pragma.htm
Jetzt wo man nur mehr ein bestehendes Codegerüst anpassen muss ist es eh leicht zu optimieren, also viel Spass.
Im Moment reicht es eh wenn du den Leuten eine angepasste epgdb.py postest zum Austauschen.
Und Ghost wird nicht so gerne haben wenn du die 1/2 Source id verwendest , weil das kann so einiges kaputt machen, so ist die Trennung klar und deutlich und scheint auch zu funktionieren.
Ich bekomme die folgende Meldungen wenn ich eine andere liste einlesen nach einander. Die erste geht aber die zweite nicht obwohl die vorige import fertig is. Die epg.db-journal wird dann noch immer geschrieben. Wichtig ist es nicht weil import nicht addiert aber 'excludes' existing events.
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] updating status ...[EPGImport] ### importEvents exception:
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is locked
Jan 01 17:10:07 dm7080 enigma2[1583]: [EPGImport] ### importEvents exception: database is lockedIch finde es noch immer das beste um erst eine leere epg.db, wann es möglich, ist ein zu lesen und dann die import zu tun. Meine bestehende epg.db ist uber 100MB und wenn ich 2000 events einlese 300KB dan habe ich noch immer ein egd.db die über 100MB ist.
Ich werde es wieder probieren mit vacuum ob die nun wohl packt.
Nochmals das ganze Plugin ist so designed um EINE epg.dat zu schreiben, da konntest du auch nicht mehrere EPGs hintereinander rein landen. Und genauso ist es auch in der epgdb.py gemacht, es werden ALLE Sachen gelöscht und dann geladen was du ausgewählt hast. Ladest du nochmals was anderes wird wieder ALLES gelöscht.
Wenn du selektiv löschen willst würde das zwar theoretisch auch gehen aber du kriegst dann ziemlich komplizierte where statements bei den deletes und das ist nicht so einfach sauber hinzukriegen und würde dann auch wieder besch* performen.
Wenn du mehrere EPG Quellen haben willst selektiere sie alle und lade sie auf einmal das geht soweit ich gesehen habe problemlos - ich kann Erotic + DE/AT/CH + UK auf einmal laden und alles ist da.
Und ich kann das jetzt beliebig oft wiederholen nur ab dem 2. mal dauert es halt länger weil die deletes gemacht werden müssen. Theoretisch könnten wir auch auf das saven der EPG datenbank verzichten und eine frische/leere anlegen, weil wenn wir sowieso alles rauslöschen ist das save fast nutzlos.
Natürlich könnten man nur die T_Events für die service_ids löschen die der loader ladet, und die descriptions und data Tabellen einfach den Triggern überlassen, aber nachdem das Housekeeping nicht funktioniert für fremd geladene daten wird die tabelle sich dann immer weiter aufblasen - allerdings könnte man beim delete alles löschen das älter als die aktuelle zeit minus dem old epg timespan ist und so verhindern das sie zumüllt.
Bitte aber die Trigger zu beachten, sprich wenn du T_Event was löscht wird T_data automatisch aufgeräumt,... Und wen du T_Service löscht wird im T_Event alles was das referenziert entfernt - das hatte ich sogar schon im Code statt den ganzen delete auf alles. Wenn du willst kann ich das wieder reinmachen, allerdings darfst du dann die Indexes nicht löschen sonst bist du tot was die performance angeht.
Aber das mit den Triggern erinnert mich daran das die Delete reihenfolge derzeit nicht optimal ist .
Und wenn du immer die gleichen EPG Quellen ladest wird die epg.db auch immer ziemlich gleich gross werden, insofern ist das schrumpfen mit vacuum und dann wieder aufblasen auf die selbe Größe mit insert wenig Mehrwert.
Du musst immer unterschieden wie man es testet und entwickelt und wie es die User benutzen - die Haken einmal an welche EPG sourcen sie haben wollen und lassen es dann täglich laufen und aus.
OK, ich denke ich habe es hingekriegt das man auch einzeln laden kann und alle anderen Events erhalten werden - aber jetzt ist die Performance wieder wie vorher, willst du das wirklich testen ?
Wobei dann ist unsere Lösung bereits besser als das was der Mitbewerber kann wenn wir selektiv pro Kanal laden können und der Rest bleibt wie er ist 
Sicher und die performance war immer gut. Und dass ich nun vollem EPG haben mach mich Freude jedes mal wenn ich es sehe auf die Fernseher.
Meine weise vom denken ist. Die anwesende EPG event konnen nicht upgedatet werden durch die box weil die external sind und dan bleiben nur wenige sender uber die nicht im XMLTV sind. Also nehme ich an das die Internal Data events auch deleted werden im die r23 version wenn XMLTV wird benutzt.
Ich denke die Event saving version is die weg su gehen und mach alles sehr flexibel. Will ich sicherlich testen.
Wie behandelt DMM die outdated events und werden die in memory schon deleted?
DELETE FROM T_Event where service_id=?
Das ist das Geheimnis - du löscht also nur Events auf dem sender den du gerade ladest, die restlichen Tabellen werden dann über die Trigger aufgeräumt.
Und alte Events sind dann natürlich auch weg.
Das Problem ist dann aber wenn du aufhörst EPG Daten auf einem Sender zu laden, dann hast du events mit Fremder source drinnen womit keine aktuellen über DVB genommen werden. Ich könnte allerdings noch ein delete mit where datum < now (bzw. keep old epg) reinmachen, damit auch alle alten Events enfernt werden, dann würde der Eisberg mit jedem Laden kleiner werden bis halt alle externen Events gelöscht wären und dann würden wieder live EPG Daten kommen, allerdings erst wenn alles an geladenen abgeschmolzen wäre.
Sonst müsstest du wieder die epg.db löschen um sofort wieder Live EPG zu haben.
Soll ich das auch noch reinmachen, damit wir wenigstens ein gewisses Housekeeping haben für alle Sender ?
Exzellent.
Das aufräumen vom alten Events nimm dann die Anfang+Dauer < epoch dann macht das Programm die housekeeping.
Danke für das bedenken diese eleganten Losung.
Na gut, weil das nur 2 Codezeilen sind
cmd = "DELETE FROM T_Event WHERE changed < datetime(?, 'unixepoch')"
self.cursor.execute(cmd,self.epoch_time)Wobei das delete über die Trigger gar nicht so schlecht performed, obwohl man dann die indizes behalten muss.
Scheinbar gefällt der Kit den Leuten wenn ich mir so die Downloads ansehen und das keine Problemmeldungen mehr kommen.
Hoffentlich bleibt das so, weil wie schon gesagt es muss auch mal Schluss sein mit der Bastelei an der epg.db und der aktuelle Codestand ist ausreichend stabil und performant und kann durch msatter's Ideen auch schon mehr als die alte Lösung, ich denke damit kann mal jeder erstmals leben und das Jammern hat ein Ende.
Auch wenn ich das nicht nutze, so damke ich dir trotzdem für die investierte zeit in diese lösung
In Summe war das nicht so arg, etwas über 2 Manntage. und ich musste auch ca. 1/2 tag diverse Enhancements und Anpassungen machen und Probleme im Plugin verstehen und fixen.
Die epgdb.py sollte jetzt hoffentlich als Anleitung ausreichen wie man die epg.db befüllt.
Jetzt warten wir mal ob sich auf der CrossEPG Seite noch was tut 
Wobei ich das mit dem gewonnen Wissen jetzt wohl auch relativ simpel zum Laufen bringen könnte, allerdings macht das als embedded Lösung im enigma2 mehr Sinn, und DMM hat das scheinbar auch im den Sourcen in der epg.db schon vorbereitet, also mal sehen abwarten ... alledings jetzt entspanner und nicht mehr EPG los.
Und ich nutze das auch nicht
...Jetzt warten wir mal ob sich auf der CrossEPG Seite noch was tut
Wobei ich das mit dem gewonnen Wissen jetzt wohl auch relativ simpel zum Laufen bringen könnte,...
Wieso?
Was kann CrossEPG denn, was Du nicht schon realisiert hast? Kann das noch mehr (Kaffee kochen zB?)