Das hat nichts mit rauf oder runter zu tun, für Now/next funktioniert das Anzeigen der Langen EPG Beschreibung sowideso und mehr siehst du in der Kanalliste nicht.
Und das dauert einfach ein paar Sekunden bis die Daten geladen und angezeigt werden.

Das man auf Info keine EPG bekommt obwohl es da ist ist ein bekanntes Problem. Als Workaround bis DMM sich das angeschaut hat schau mal ins Webinterface dort sind die EPG Daten da und man kann dort auch Timer dafür programmieren.

Womit es klar ist das es nicht an den EPG Daten liegen kann ...

du musst nur die code im WebInterface also die EPG.py und in der EpGList.py vergleichen wie da die EPG Daten in die Liste geholt werden. Die search strings für den Query die an den C++ Teil übergeben werden sind nicht die gleichen und damit kommt scheinbar auch was anderes/mehr zurück.

NUR wie diese Search strings funktionieren und nicht wirklich dokumentiert soweit ich weis, aber nachdem Reichi das EPG pflegt nehme ich an er hat seine Sachen bereits besser an mögliche Externe EPG Daten angepasst.

es wird mir RIBDT gesucht und jeder Buchstabe sagt dann was returned werden soll, T ist z.B der Title, machst du am Ende aus dem T ein R draus kommt die (service) reference in das Beschreibungsfeld der liste zurück der bei N der (channel) name.

Das steuert also wie im C++ der Query der die Liste performant erstellt gefüllt werden soll - und da kommt scheinbar bei externen daten noch nicht alles wie es soll.

Die Frage ist allerdings - liegt es am enigma2 oder an unseren Daten die wir in die epg.db stopfen

Und Langbeschreibungen solltest du jetzt immer haben - wenn keine geliefert wird kopiere ich da in der derzeitigen version halt die Kurzbeschreibung nochmals rein um Probleme zu vermeiden

Du sagst nicht mal was du liest - was sollen wir mit der Fehlermeldung anfangen ?

Und nein das hat nichts mit Quick Button zu tun

Wenn ich diesen pointer mit den Daten in der EpgSelection mit print ausgebe, also

print "[GUTEMINE]",  cur

Dann kommt bei den funktionierenden:

[GUTEMINE] (<enigma.eServiceEvent;proxy of <Swig Object of type 'ePtr< eServiceEvent > *' at 0x2416158> >, <ServiceReference.ServiceReference;  >)

Und bei denen wo das Add Timer ausgeblendet wird:

[GUTEMINE] (None,<ServiceReference.ServiceReference;  >)

Und bei None blendet der code halt auch richtig das AddTimer aus. Es wird also kein Pointer zum EPG event zurück gegeben, womit er in Folge eben auch nicht programmierbar ist.

Also ist es eher umgekehr - der Query liefert sehr wohl Daten, aber die event id stimmt hier irgendwie nicht womit man damit eben nichts weiter anfangen kann.
Und wirklich Spass macht das debuggen und zu versuchen zu verstehen was da schief läuft auch nicht.

So wie ich das verstanden habe geht der Autotimer doch eh mit den meisten Sendern die nicht gerade aus UK sind - und wenn nicht soll ich den auch noch fixen ???

Bitte lest nochmals was ich als ich mit der Arbeit begonnen habe geschrieben habe.

Wendet Euch doch mal an die Hersteller der EPG Lade Plugins, eigentlich haben die jetzt 0 Entschuldigungen mehr den OE2.2 Suppport nicht anzubieten.

Du kannst gerne im Pli Board nachlesen was es alles an freundlichen Antworten und Ratschlägen zum Thema Rytec XMLTV Support für OE2.2 gab.

Und hier im Thread steht auch was zu CrossEPG was angeblich sogar VOR meinem Machwerk funktioniert hat.

Ihr könnt auch dort gerne Danke für den Fisch sagen und ... weiter warten.

But this "Add Timer" Yes/No Business gets more and more mystique.

I found now an example with True Drama (works) and True Movie 2 (doesn't work) these are channels on the SAME Transponder and from the same vendor and behave different

If I thne press Info and BLUE for Multi EPG instead of Yellow for Single EPG then I can forward with Blue to the available EPG so the data ist SHOWN but as at the returned EventId is always empty it fails to give the AddTimer Button

And adding events to existing ones by ommiting the DELETE will create strange behaviour as the ids could be re-used.

Ich habe noch den Bug mit den gelegentlichen getitem exceptions gefixed, anbei ist eine r25 wo der Fix dafür drinnen ist.

Dda wird jetzt auch der Inhalt der T_Service Tabelle beim laden weggeworfen, weil falls ihr ständig Quellen wechselt beim Testen macht das Sinn, sonst sind Sender als extern versorg angelegt, die dann gar keine Daten geladen kriegen.

I already explained that I don't really like the idea of vacuum cleaning the db all the time, when you trop the content of entire tables there should be enought continuous free space to prevent framentation - ans as the db mainly runs in memory even this is not a problem. And then writing it to Filesystem is already a kind of defragmentation.

But if you confirm that the overhead is marginal I might consider it.

Du liegst insofern falsch als es hier ums EPG laden geht und NICHT umd die EPG Lösung von DMM - die funktioniert, sogar besser als alles was bis jetzt existiert hat.

ich habe JEDE Menge an FALSCHEN Daten in die epg.db gejagt beim Entwicklen und das hat kein einziges mal Enigma2 gecrashed.

Mit der epg.dat kann ich das 100x crashen ohne mich anzustrengen.

HEUREKA

Ich sollte mehr auf mein Bauchgefühl hören ...

Ich sagte doch schon mal hier im Thread dass der einzige Teil an der epg.db Datenbank der mir noch immer unklar war die dvb_event_id war und ich einfach angenommen habe, dass es eine unique ID sein muss und das dann so gelöst habe das ich einfach einen counter bei jedem event raufgezählt habe,

ABER wenn man die DVB Standard Doku dazu liest dann stellt man fest das die id nur unique pro Sender sein muss, und das es ein 16BIT Integer ist - also der größte Wert der erlaubt ist damit 65536 = 64 k ist

UND wir laden bei DE/AT/CH ca 40k events, bei UK aber 80k - fällt Euch was auf????

EBEN - Der C++ code im enigma2 hält sich scheinbar an den Standard und findet damit EPG Events wo die ID größer ist als 64k nicht mehr richtig in der Datenbank.

Ausserdem ist die dvb_event_id eigentlich nur dazu da um doppelte events rauszufiltern (die müssten dann gleiche id haben und damit erkennbar sein).
Durch den unique hash auf die Beschreibungen können echte Doubletten aber sowieso gar nicht vorkommen, also braucht man die dvb_event_id im Moment gar nicht wirklich.

Und der Hash ist eigentlich in der DB als signed 32 Bit integer (weil auch massig negative Werte vorkommen), das python macht aber ein unsigned Integer draus, was auch korrigiert gehört.

Neuer Kit wo das alles entsprechend angepasst ist findet Ihr im Anhang - viel Spass mit EPG für UK

Insofern muss DMM auch gar nichts anpassen, wir müssen uns halt einfach auch beim EPG an die DVB Spezifikation halten

LG
gutemine