Bitte NUR die aktuellen Kits benutzen, gerade bei den rytec sourcen nur mit der sources.xml von der r4 testen sonst kriegt man teilweise steinalte Daten die natprlich nicht angezeigt werden !!!!!

Und wenn Ihr selber rytec source files habt einfach als xxx.sources.xml ins /etc/epgimport directory kopieren.

ls  /etc/epgimport
current.sources.xml

Die current stammt aus dem r4 deb damit man wenigstens eine hat mit quellen. Aber achtung rytec.sources.xml wird ignoriert, also mit anderem xxxx anfangen.

Und das man auf Blau und gelb ein bisschen warten muss bis die Daten im Hintergrund geladen sind habe ich auch schon im Thread erklärt.

Im Anhang ist eine r16, da werden NUR mehr die alten XMLTV Events gelöscht statt alle Daten nieder zu prügeln, damit sollte der DB locked Fehler seltener auftreten.

Und outdated epg events sollte das housekeeping der epg db entfernen, wobei da vom Plugin beim laden sowieso alle externen XMLTV Events gelöscht werden, sollte ein neuer load dann eh nur wieder aktuelle events bringen.

Wobei die rytec sourcefiles ja auch nur täglich aktualisiert werden, je nachdem wann man runterladet wird man dann halt events haben die an diesem Tag eigentlich bereits vorbei sind, aber die werden sowieso nicht angezeigt.

Das ist KEINE Release und ich werde auch sicher KEINE machen, das Plugin hat einen Maintainer und ich bin das nicht und ich habe auch NICHT vor irgendwas von meinen Änderungen dort einzuchecken.

Die aktuellen Versionen sind so gebaut das sie denke ich auch weiterhin mit den anderen boxen funktionieren (dann wird der alte code aus epgdat.py statt mein epgdb.py verwendet) mehr werde ich nicht tun.

Bitte vergesst nicht das einer der Gründe warum ich mich an Ihrem Plugin 'bedient' und es einfach aufs OE 2.2 umgehämmert habe mein von gegenseitiger Achtung geprägtes Verhältnis zu unseren Holländischen Freunden war

Mit der r16 kann man aber mehrmals die selbe source laden, gerade 3x hintereinander mit DE/AT/CH probiert. Insofern sollte der Trick um die epg.db wieder zu leeren nicht mehr nötig sein, aber ich habe halt so entwickelt, damit weis ich das man wenn man irgendwo beim laden abbricht oder komische Sachen passieren man damit wieder in einen konsistenten Zustand der epg.db kommen kann.

Es ist beim Testen immer eine gute Idee mit einer sauberen und leeren epg.db zu beginnen, allerdings habe ich schon gesagt das ich nicht sicher bin ob die Anzeigeprobleme von meinem code kommen, die Quellen der epg daten werden aus der sourcelist scheinbar mit random genommen um die load zu verteilen und nicht alle Quellen sind scheinbar gleich gut/aktuell.

Und wenn du alte Daten ladest wird nichts angezeigt, ich habe in den debugging output zwar etwas eingebaut damit am Schluss auch ausgegenen wird wie viele events in der Vergangenheit sind aber das ist auch nur eine Zahl um ein Gefühl zu kriegen ob es gut gegangen ist.

ich habe noch keinen sauberen Weg gefunden die epg sprache in die T_Data richtig einzutragen, evt. kann das Problem von da kommen das ich nur "" reinschreibe statt eng oder deu.

In der xm ist diese info scheinbar nicht, weil nichts in diese Richtung übergeben wird, ich nehme also an der epg.dat war das egal und das ist ein neues Feature der epg.db um Multi Language epgs zu ermöglichen.

Ich könnte aber eine Einstellung ins Plugin machen um das zu testen aber Ihr müsstet mir eben die nötigen Werte sagen ?

Wobei ich denke das sind die texte mit 3 Buchstaben so wie im Wiki beschrieben:

http://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

Kann mir wer eine liste machen von allen nötigen ?

Natürlich musst du nicht warten, das Plugin kann ja auch zur Fixen Zeit und im Hintergrund laden oder bei jedem Booten,...

ABER das habe ich nichtmal ausprobiert, bitte solche Sachen durch das Lesen in der XMLTV Plugin Sektion im Board bei unseren Holländischen Freunden klären und in diversen Wikis.

Aber ja, schön langsam scheint es zu funktionieren ...

Danke, aber ich komme schon zurecht. Jeder Mensch hat halt auch nur 2 Mittelfinger

Ich hätte jetzt noch eine Frage an DMM:

in der enigma.py findet man auch noch eEPGCache.setCacheTimespan wo man scheinbar eine Zeit übergeben kann wie oft der EPG Cache in die Datenbank rausgeschrieben werden soll, oder verstehe ich das falsch?

Was ist da der Default wert wenn man nichts angibt, und würde es reichen wenn man dort einen extraem grossen Wert übergibt damit enigma2 alles cached und dann erstmal gar nichts in die epg.db rausschreibt, weil das würde sinn machen während ich die epg.db befülle, weil ich sie nachher sowieso wieder lade und dann alle updates die in der Zwischenzeit passieren verloren gingen ?

Weil die DB Lockj Fehler die ich immer wieder kriege passieren scheinbar wenn enigma2 gerade was in die epg.db schreiben will, während das Plugin sie auch aufmacht um zu löschen/ zu schreiben, und ich bräuchte daher eine Methode um das zu verhindern - wofür sich eben das CacheTimespan anbieten würde. Deswegen passieren die Locks auch fast nicht wenn ich beim Laden auf einem Sender bin wo kein EPG ausgestrahlt wird, wiel dann wird auch nichts in die epg.db geschrieben und es kann kein gegenseitiger Lock passieren.

Ideal wäre es wahrscheinlich wenn man zB -1 als Zeit übergeben könnte und damit enigma2 überhaupt NUR mehr unbegrenzt im Cache arbeiten lassen könnte (also sozusagen unendlich als Wert wann wieder mal die db rausgeschrieben wird), und nach dem Load der epg.db müsste man da halt wieder 0 oder den Default Wert reinschreiben damit wieder ganz normal die EPG events wo man keine höhere priority hat weil sie vom xmltv kommen auch wieder rausgeschreiben werden.

Geht das oder müsste/könnte man das anders lösen ?

LG
gutemine

PS: Und gutemine hat keine Feinde - wir Gallier verklopfen halt alle gerne ... die Römer.

[EPGC] set cache timespan to 0 days!

Ich habs einfach ausprobiert, wenn ich da 0 übergebe dann sagt er die Einheit sind TAGE?

Insofern habe ich das wohl missverstanden, ist das die Dauer wie Lange EPG in die Zukunft gehalten wird, dann müsste ich es wohl umgekehrt benutzen - 0 würde dann kein EPG heissen, also alle Updates müssten ignoriert werden, und am Ende setze ich es wieder auf was sinnvolles wie 5 Tage oder den Wert aus dem Plugin wie lange Long descriptions in die EPG Datenbank geladen werden sollen ???

Weil wenn ich 0 übergebe sagt er nämlich auch noch

[EPGC] db thread stopped

Und das wäre ja was ich brauche damit keine locks auftreten können wenn ich den Inhalt aktualisiere?

In der enigma.py gibt es auch noch:

eEPGCache.Lock 
eEPGCache.Unlock

Würde denn das helfen die Locks loszuwerden damit man sorgenfrei updaten kann ?

Ich habe das in eine r19 reingemacht, bitte testen ob vielleicht damit die Lock Fehler nicht mehr passieren

EDIT: Ja das funktioniert jetzt besser ... und langsam verliere ich die Lust da daran weiter zu basteln wenn Ihr so viel mithelft
Funktionieren tut es ja, also ist meine Mission (sofern man in diesem Fall davon sprechen kann) eigentlich erfüllt.

To be honest I don't know the reason for this - could be because Now is still coming from Live broadcast.

But it works for german channels that I load via the Plugin, so it seems to be not a generic problem of the loaded EPG data.

Maybe it could be due to the fact that when importing language I pass a blank to the epg.db, because the xml epg data doesn't contain language information that I could use.

if you want to test this theory edit the epgdb.py and change

cursor_data.execute(cmd, (self.event_id,title_id,self.short_description_id,self.extended_description_id,'')

to pass always english:

cursor_data.execute(cmd, (self.event_id,title_id,self.short_description_id,self.extended_description_id,'eng')