Danke, mit den INSERT und select examples von Ghost und den Änderungen damit auch Fremde Quellen ihren bestand haben sollte es dann eigentlch zu schaffen sein.

Wobei wie ich schon am Anfang sagte, ich bin nicht der Ideale um sowas zu proggen, gescheiter wäre enn DMM eine EPGDatabase classe mit open/close/insert/delete als Funktionen machen würde wo man die Rohdaten übergibt und die sich dann um die Tabellenabhängigkeiten und die Inserts kümmert.

Weil dann würden die vorhandenen Plugins nur mehr ein import machen müssen und die routinen aufrufen, was wahrscheinlich schneller erledigt wäre als das was wir jetzt angefangen haben-

Weil wir müssen uns mühsam das Wissen wie es funktioniert erarbeiten während Ihr es schon habt

Aber andererseits machst es auch Spass, also schauen wir mal wo uns die Reise hinführt.

Wenn das Codegerüst steht und man siehst das und wie es funktioniert denke ich werden sich schon auch andere einfinden die es vielleicht etwas eleganter lösen können als das was ich da jetzt mache.

LG
gutemine

das versuchen wir ja gerade, aber ich bin ziemlich sicher das Ihr das auch in Python schneller hinkriegen würdet als wir/ich

Das C++ gewrapped will ich gar nicht haben, wo wäre denn da der Spass.

Ich habe mir ja den VideoDB code von Dr. Best angesehen, um zu sehen wie man sqlite im Python benutzt, wenn ER das machen würde wäre es wahrscheinlich so wie es alle gerne hätten - nur ist er noch bis Weihnachten unterwegs und will sich das dann sicher nicht gleich unter den Weihnachtsbaum legen.

Aber eines nach dem anderen, ich baue halt jetzt mal das erste select statement von Ghost nach, um die id nicht nur Q&d mit der sid zu kriegen, sondern alle infos aus der service ref des senders zu verwenden so wie es sich scheinbar gehört. Und dann muss ich sowieso auf den nächsten enigma2 tarbal warten damit eine xmltv source mit entsprechender Priorität in der epg.db auch seinen Stand hat.

Wobei wenn ich es jetzt als Code schreibe mache ich das alles wie ein Volltrottel und ohne Rücksicht auf Verluste in eine einzige python Routine, bis es endlich macht was es soll, und selbst DAS wird mich wahrscheinlich das ganze Wochenende kosten - und ob ich dann Lust habe das noch schön mit Fehlerhandling zu versehen und in routinen einer ordentlichen Python classe zu packen ... kann ich eben NICHT versprechen ...

Nur damit es nicht heisst ich hätte Euch nicht gewarnt

PS: Ausserdem muss ich auch ein Paket auspacken und in Betrieb nehmen - Danke.

Ich versuche gerade so eine Art Hello World' table insert zu machen um zu sehen ob ich einen zusätzlichen EPG Eintrag für eine 'Hello World' Sendung zusammen bringe die dann im enigma2 auch angezeigt wird.

Eigentlich dachte ich ich würde einfach mit der selben service ID wie der online Update sachen in die DB Tabellen stopfen, aber wenn ichGhost's rpely richtig verstanden habe würde das nicht funktionieren, weil sobald man dann auf den Sender zappt würden die Einträge von denen die gesendet werden überschreiben.

Ausserdem sollte das mit EPG Datenbank ja BESSER funktionieren als wie bis jetzt wo man mehr oder weniger die ganze epg.dat ersetzt hat.

Durch die Database soltle man also EPG aus verschiedensten Quellen zusammenmischen können und ggf. auch dav vorhandene manipulieren und ergänzen.

Also habe ich in einem ersten Schritt mal versucht das xmltv in die T_Source einzutragen und dabei so wie erklärt eine höhere Priorität zu vernweden

sqlite> select * from T_Source;
0|Sky Private EPG|0|2014-12-06 16:27:46
1|DVB Now/Next Table|0|2014-12-06 16:27:46
2|DVB Schedule (same Transponder)|0|2014-12-06 16:27:46
3|DVB Schedule Other (other Transponder)|0|2014-12-06 16:27:46
4|Viasat|0|2014-12-06 16:27:46
sqlite> insert into T_source values ('99','Rytec XML','99',DATETIME('now'));
sqlite> select * from T_Source;
0|Sky Private EPG|0|2014-12-06 16:27:46
1|DVB Now/Next Table|0|2014-12-06 16:27:46
2|DVB Schedule (same Transponder)|0|2014-12-06 16:27:46
3|DVB Schedule Other (other Transponder)|0|2014-12-06 16:27:46
4|Viasat|0|2014-12-06 16:27:46
99|Rytec XML|99|2014-12-06 16:30:13

Das sieht schon mal brauchbar aus und wenn ich das bei gestopptem enigma2 machen und dann nachher enigma2 starte und wieder stoppe bleibt mir das in der epg.db auch erhalten.

Die Frage ist jetzt allerdings wenn ich mit id 99 jetzt einen Eintrag in die T_Event mache ob der auch genommen wird - sprich ist im aktuellen enigma2 binary bereits implementiert das EPG aus Quellen mit höherer Priorität gewinnt, oder muss ich zum ursprünglichen Ansatz zurück und mit 1-3 sachen in die Tabellen zu schreiben ?

Und verwendet DMM auch das DATETIME('now') vom SQL oder macht sich den Zeitstempel selber aus der systemzeit - weil aus den zeitstempeln von oben sieht es eigentlich so aus wie wenn auch der mit DATETIME gemachte 'stimmt' also die jeweilige zeitzone der Box ignoriert und UTC hat ?

Fragen über Fragen ...

Na ja ich dachte eher an ein blending der Daten - sprich ich könnte die EPG Beschreibung mit daten aus der Movie Datenbank 'ergänzen' oder der Autotimer könnte statt doof nur timer anzulegen auch ein 'Auto Timer empfohlen' beim event in der Beschreibung anhängen, oder man könnte bei den Serien den Titel oder Folgennummer abändern statt das mühsam mit der MovieDB zu fixen, etc.

Insofern will ich das mit dem updaten/blenden der vorhandenen EPG nicht gleich ad-acta legen ...

Wenn das mit der Priority aber erst beim nächsten Update kommt ist es im Moment etwas mühsam zu debuggen, weil ich muss dann den EPG in der Sendungsliste checken indem ich mir dort sender ansehe wo ich noch nicht hingezapped habe - wenn ich dort EPG daten angezeigt kriege obwohl ich im Python alles lösche um inkonsistenzen zu verwemdien vor den inserts dann hat es funktioniert ...

Mal sehen ob ich das hinkriege ...

Blöde ist das dann aber live EPG Änderungen wie bei Sendungsverschiebungen nicht mehr durchkommen würden und immer das geladene an EPG daten gelten würde, aber ich denke damit kann man erstmal leben.

Aber umgekehrt müsste das doch auch heissen wenn ein Sender nur Now/Next sendet das dann auch mit Priority 0 zusätzliche daten erhalten bleiben mussten, weil dann einfach nichts kommt, um einen Anlass zu haben die zusätzlichen Daten zu löschen?

Oder habe ich das auch falsch verstanden ...

Na ja egal. schlimmstenfalls müssen wir halt die paar Tage warten und Weihnachten mit genug Zeit es zu debuggen ist auch bald ...

Ich brauche das sowieso nicht, für mich ist das eher Spielerei um zu sehen ob ich es hinkriege, bzw. die nötigen Infos zu sammeln das es vielleicht auch wer anderer zusammen bringt.

OK & Danke

Ich habe in der Zwischenzeit den code mal grob zusammengezimmert, aber jetzt schmeisst es mir massig den Fehler, scheinbar passt Ihm da ein Datentyp noch nicht oder ich verwende die hash routine aus der enigma.py nicht richtig

Zitat

swig/python detected a memory leak of type '__u32 *', no destructor found.

Aber wenigstens schmeisst es bei den Inserts keine Database Fehler mehr ... was auch schon fast ein Erfolg ist.

Ich packe das trotzdem mal in ein *.deb und lade es hoch, alles nötige für das epg.db Interface steht jetzt in der epgdat.py (der Rest ist bis auf die Anpassungen ans OE 2.2 von weiter oben das original Plugin), mal sehen ob wir das zum Laufen kriegen.

Die Performance ist im Moment natürlich noch Sch* weil ich das epgdat.py noch mit print fürs Debuggen vollgestopft habe und nach jedem update ein commit mache, aber so sieht man wenigstens was abläuft wenn die Daten aus dem xml in die epg.db importiert werden.

und ja ich schäme mich für den code - aber das hat mich noch nie abgehalten

Vielleicht könnt Ihr ja mal drüber schauen ob ich was vergessen oder falsch verstanden habe ...

EDIT: Das rytec deb Paket mit den Quellen ist weiter oben im Thread, und ich teste es immer mit Germany/Austria/Swiss als Quelle angehaked auf Blau und Manual Load auf Gelb damit ich in telnet mitlesen kann was an Daten kommt und mit insert in die DB gestopft wird.

LG
gutemine

man sollte einfach die Fehlermeldungen LESEN - der hash ist ein unsigned integer und mag es scheinbar nicht wenn man ihn mit %d als signed ausgibt ... ich habe den kit gegen eine r5 ersetzt wo mit %u ausgegeben wird - NUR der Fehler geht nicht deswegen weg

Ja, aber im Moment ist das wirklich nicht wichtig, man muss Prioritäten setzen

Wenn der Code die epg.db Tabellen erstmal richtig befüllen kann dann können wir uns in Ruhe überlegen ob und wie wir Ihn aufräumen und verhübschen könnnen.

Du darfst auch nicht vergessen, das ich nicht der Maintainer der xmltv Plugins bin. Ich habe mir den code nur geborgt um ein funktionierende Framework zu haben und nicht auch noch die xmls parsen zu müssen. Ob Milo in seinem Plugin OE 2.2 Code haben will ist dann aber eine andere Sache, daher kann das ganze auch mit einem fork oder was auch immer enden, was ich dann aber auch nicht maintenen werde.

Mir gehts ja NICHT darum ein epgdb Plugin zu machen, oder ein vorhandenes an mich zu reissen, sondern zu beweisen das man eigentlich nur eine Seite Code braucht um die epg.db zu befüllen - und mehr ist es im Moment noch nicht, auch wenn es noch nicht so funktioniert wie es sollte.

Ich bin aber ziemlich Beratungsresistent - ich halte es da mit Frank Sinatra

http://www.lyricsfreak.com/f/f…atra/my+way_20056378.html

Und wenn du ein komplexes Problem lösen willst musst du es vereinfachen, nicht komplizierter machen.

Bitte kann mir wer einen Tip geben wie wir den meory leak error loswerden, weil selbst wenn ich für alle inserts nur ein commit machen und die ganzen print rausnehme läuft es dadurch endlos nur um dann nach minutenlangem Warten festzustellen das die Tabellen zwar massig mit events und Beschreibungen befülltt sind aber nichts davon angezeigt wird.

Weil so lässt es sich praktisch nicht debuggen wo der lin in den Tabelllen bricht

selbst wenn ich am Anfang die ganzen T_Event und T_*Description und T_Title Einträge löschen dauert ein durchlauf zu lange und enigma2 wird fast unbedienbar weil ständig die Sanduhr kommt.

Ähm ein delete OHNE select und where geht blitzschnell, und genau das mache ich im Moment.

Und die Inserts sind auch nicht wirklich das problem weil sie ohne primary key passieren, womit die Datenbank wissen sollte das sie es einfach als neue row anhängt. Wenn ich mit den commits spare sollte das schon gehen, im C code von DMM wird es auch nicht viel anders sein. Das mit der rowid des letzten inserst probiere ich aus. wobei das im Moment nicht wehtut, weil ich es ja nur für die system_id 1x pro sender brauche, für die Events mache ich jetzt schon die inserst mit eigenem Zähler, mehr macct die Datenbank ja auch nicht.

Bitte nicht vergessen der sqlite code ist einfach Q&D aus Dr. best seinen routinen für den DM accesss geklaut, erstmals müssen die insert statements richtig erstellt sein um fürs enigma2 gültige EPG Datenbankeinträge zu erzeugen.

Derzeit bremst den code mehr das 10000x der Memory Leak ausgegeben wird, da dürfte was mit der statisch im swig gewrappten routine für den Hash einfach nicht stimmen - hat wohl keiner probiert sie mehrmals hintereinander aufzurufen, bis jetzt lag sie ja brach rum. Und das macht das debuggen praktisch unmöglich weil mal vom speed abgesehen dann die interessanten Meldungen zwischen 10000 Zeilen unnötiger Fehlermeldung stecken.

Wenn ich übrigens statt dem generierten hash einfach auch einen Zähler inserte (muss ja nur unique sein) ist es schnell genug und gibt keine Fehler, ausser z.B. Sachen wie wenn lange und kurze beschreibeung gleich sind weil dann natürlich der Hash gleich ist, oder wenn in der Description "xxxx" vorkommt, weil das python dann glaubt der textstring ist zuende, etc. Aber das sind Sachen die man debuggt wenn mal der rest ins Laufen kommt.

Also keine Angst, das wird schon. Nur dann funktioniert ohne hash natürlich ... nichts.

Also müsst Ihr Euch halt gedulden bis Reichi das mit dem hashs gefixed hat, vorher macht das wenig Sinn ... und dann geht es schon weiter.

Danke fürs Feedback, im Moment ist es ja mit commits und print zugepflastert um bei der Arbeit zusehen zu können. Durch das try/except muss ich aber wenigstens nach jedem event ein commit machen, weil sonst wird es inkonsistent wenn Fehler passieren (und ich habe gerade ein paar mögliche reineditiert wie bei "" wenn die in der Description vorkommen.

Und ja, das lässt sich mit dem eigenen cmd string vermeiden das mit dem like ist besser als das "=", und wenn oder long & extended description gleich sind sollte ich halt kein insert mehr machen, etc...

Und ich denke auch wir müssten eigentlich mit 3 routinen auskommen, eine für open (mit dem epg save damit die datenbank alles hat was das enigma2 bis jetzt gesammelt hat)), eine für close (mit dem load, damit alels neue dem enigma2 bekannt gemacht wird) und eben mit dem update über alle services und über alle events. Insofern ist das so wie es das xmltv macht eh schon recht datenbanlfreundlich gestaltet. Natürlich kann ich das auch in eine packen, aber da die alle nur 1x aufgerufen werden sollte das von der Performance ziemlich egal sein.

Ich werde aber mal am Abend versuchen die Verbesserungsvorschläge einarbeiten, aber es kann sich auch gerne wer von Euch daran versuchen, weil ja es tut weh den code anzusehen ....