Bitte einpacken und ins Dorf der unbeugsamen Gallier senden, sobald sie angekommen ist mache ich mich an die Arbeit ...

Bitte das war ernst gemeint - nicht das mit dem Arm

Aber das xmltv Plugin schnell mal umszuschreiben das es mit sqllite die Sachen aus den xml's statt in ein epg.dat file in die Datenbank schaufelt ist wahrscheinlich keine 2h Arbeit, keine Ahnung warum das keiner einfach TUT und lieber gejammer wird

Sagen wir mal so - bis zum Wochenende habt Ihr Zeit - bis dahin müsste die Post auch den Arm geliefert haben.

Und ich brauche wahrscheinlich mehr als die 2h - aber mein SQL ist auch etwas eingerostet ...

Und dann heisst es wahrscheinlich wieder ich will schon wieder beweisen das alle anderen blöde sind

Er bietet eine Hand und du willst gleich den ganzen Arm

So bin ich halt ....

Nur ich hasse halt einfach Jammerei die NICHT gerechtfertigt ist.

Milo hat das xmltv ja Plugin unter GPL gestellt also kann man es doch modden ohne schlechtes Gewissen zu haben oder lange fragen zu müssen ...

Ich habe mir den code mal angesehen - es sind genau 5 (in Worten FÜNF) Zeilen in der plugin.py die man anpassen muss damit das Plugin unter OE 2.2 läuft und wie unter OE 2.0 gewohnt die epg.dat befüllt ohne zu crashen.

Diese epg.dat wird natürlich ohne weitere Anpassungen im Plugin vom enigma2 4.2 komplett ignoriert werde, aber damit hat man bereits 80% dessen was man vorher hatte - sprich das Laden der EPG daten auf die box und diese im python code zur Verfügung zur gefälligen Verwendung für die neue EPG Datenbank.

Im Prinzip stört das Plugin damit erstmal überhaupt nicht wenn es läuft, aber Leute die begabter als ich sind müssten jetzt nur mehr ein import sqllite in den code machen und die routine die die epg.dat schreibt umhämmern damit sie sql inserts macht statt ein nutzloses File zu schreiben - und natprlich vorher ein save und nachher ein load wie Ghost es erklärt hat ....

Womit die 2h für EUCH eigentlich JETZT zum Laufen anfangen sollten um es fertig zu machen.

Wenn Euch fade ist und Ihr sonst NICHTS machen könnt probiert wenigstens mal aus ob mit den kits im Anhang auf manual updaten (Gelb im Plugin) oder wenn man fixe zeiten oder beim Booten bei den Einstellungen enabelt die EPG Events von Euren Wunschquellen geladen werden die man wie vorher auf Blau einstellt.

Und meinen Post NICHT falsch verstehen, NICHTS von den geladenen daten wird mit diesen Kits im EPG auftauchen, solange die EPG Datenbank noch nicht angebunden ist, ABER man muss sozusagen einen Arm nach dem Anderen abhacken ... und wenn man nicht damit anfängt ... wird es auch nie fertig werden.

Und geht nicht im OE 2.2 stimmt eben jetzt nicht mehr, das läuft sehr wohl und aus dem Bauch würde ich sagen da fehlt jetzt maximal eine Seite code bis auch mit der EPG Datenbank wieder alles wie gewohnt funktioniert. Weil im Prinzip muss man jetzt 'nur' noch die epgdat.py neu schreiben um sttat das file zu schreiben die Sachen in die datenbank zu stopfen. Und da das schon jetzt nur rund 300 Zeile code sind wobei das meiste davon nur zum Konvertieren auf das komische epg.dat format im DVB standard drauf geht sollte das NICHT so schwer sein wenn man es mehr oder weniger direkt in die tabellen der epg.db stopfen kann.

Der nächste Arm den man abhacken muss ist also gnadenlos aus dem epgdat.py muss man erstmal eliminieren was im OE 2.2 nicht mehr gebraucht wird und die Rohdaten einfach mit print ausgeben um es zu testen. Wenn man dann alls hat für die Datenbaktabellen ist das updaten der nächste Schritt - und wenn man vom load/save absieht ist dann dann schon alles was nötig ist.

LG
gutemine

Damit es nicht wieder heisst ich behaupte was das gar nicht so einfach ist - Iich konnte nicht schlafen und habe die epgdat.py auch noch wie versprochen gnadenlos entleert (sind statt 300 Zeilen nur mehr 70)

Statt ein im OE 2.2 sowieso unnötige epg.dat zu schreiben, gibt es jetzt erstmal einfach die empfangenen daten mit [GUTEMINE] aus, sprich man kann die EPG daten der sender die geladen wurden und die man auch in der lamedb hat, wenn man enigma2 mit systemctl stop enigma2 stopped und mit enigma2 wieder startet im telnet schön mitlesen.

Womit eigentlich NUR mehr an den Stellen im code wo ich es erstmals als text hingeschrieben habe das Laden und speichern der EPG Datenbank reingehört und eben statt den print die inserts der Daten in die Datenbank tabellen. Wenn wer sich mit SQL auskennst ist das dann nur mehr 1 Stunde Arbeit, aber ich muss mich erst dran erinnern wie das überhaupt geht und die sqlllite Befehle dafür im Pythin nachlesen, jemand wie Dr. Best der die seine Mediendatenbank auch mit sqllite befüllt schafft das wahrscheinlich sogar schneller.

Falls wer sich den Code anschauen und bereits ohne epg.dat testen, oder noch besser den felhelnde Coder ergänzen will, im Anhang ist noch eine r1, aber damit ist für heute erstmal genug herumgehackt

PS: Ich habe fast ein bisschen zu viel aufgeräumt, der counter wie viele events geladen werden wird jetzt nicht mehr aktualisiert sondern nur mehr die gesamtzahl ausgegeben, aber das wird schon wieder werden.

Ihr hattet Eure Chance es zu machen wie IHR wollt, oder bei sin zu betteln oder was auch immer.

Ich habe nur gesagt das ist nicht schwer und wenn es sonst keiner macht dann setze ich mich halt hin und mache ich es so gut wie und um zu beweisen das ich es kann.

Das CrossEPG kannn zwar vieles, aber sin hat da auch vieles zusammengestöpselt und es ist eigentlich eine wüste Mischung von Python, *.so und shellscripts.

Sobald jemand die 1 Seite code implementiert wie man EPG daten im OE 2.2 in die epg,db stopft, bin ich ziemlich sicher das er seine Ruf gerecht werden wird und auch das einbaut.

Das xmltv ist im Moment aber etwas aufgräumter und auch was die Liziensierung angeht freundlicher um es schamlos umzuhämmern, nicht umsonst war es bis jetzt eigentlich recht simpel die Sache auf den Weg zu bringen.

Und ausserdem habe ich mit unseren Holländischen Freunden noch ein Hühnchen zu rupfen

LG
gutmeine

natürlich ist schwer relativ, aber gerade weil unsere holländischen Freunde ß Motivation haben was zu tun ist es viel lustiger Ihr Teil zu verbiegen und auch verständlich warum DMM genau das NICHT tut.

Mir ist das aber einfach egal, wenn es nur darum geht rauszufinden wie es geht ist mir alles recht wo ich nicht bei 0 anfangen muss.

Aber ich schaue jetzt lieber wie weit ich heute komme - Diskussionen hatten wir wirklich schon genug ...

Jetzt muss ich erstmal Dr. best Fragen ob ich bei seinen Database*.py aus der VideoDB borgen darf, weil dann wäre es eigentlich ganz leicht.

Ich muss eh erstmal warten ob Dr. Best mir das broegn bei seinem code erlaubt (mehr als 1 Seite brauche ich eh nicht von seinen sachen), also versuche ich in der Zwischenzeit die EPG DB zu verstehen, weil wie schon gesagt mein SQL ist ziemlich eingerostet.

apt-get install sqlite3

Das bringt dir erstmal das sql interface auf commandline Ebene, dann kannst du im telnet am Besten bei mit systemctl stop enigma2 gestopptem enigma2 eingeben:

sqlite3 /etc/enigma2/epg.db

Und dann kannst du mit .tables und .schema nachsehen was du hast und mit .quit kommst du wieder raus.

Die services sind scheinbar über eine id in allen Tabellen der erste key, was auch logisch ist du wirst ja EPG für einen jeweiligen sender brauchen.

die epgda.py hat aber die service reference so wie in der enigma2 lamedb. also muss man mal schauen wie man die zerlegen muss um dann mit einem select die richtige id aus der Tabelle zu holen ... denke ich mal.

Weil erst wenn ich die id habe kann ich dann damit inserts in die anderen Tabellen machen, damit enigma2 weis das diese EPG events dann für diesen sender sind.

Ja das t hilft, aber hier ist der output vom schema:

sqlite3 /etc/enigma2/epg.db
SQLite version 3.7.17 2013-05-20 00:56:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .schema
CREATE TABLE T_Service (id INTEGER PRIMARY KEY, sid INTEGER NOT NULL, tsid INTEGER, onid INTEGER, dvbnamespace INTEGER, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE TABLE T_Source (id INTEGER PRIMARY KEY, source_name TEXT NOT NULL, priority INTEGER NOT NULL, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE TABLE T_Title (id INTEGER PRIMARY KEY, hash INTEGER NOT NULL UNIQUE, title TEXT NOT NULL, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE TABLE T_Short_Description (id INTEGER PRIMARY KEY, hash INTEGER NOT NULL UNIQUE, short_description TEXT NOT NULL, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE TABLE T_Extended_Description (id INTEGER PRIMARY KEY, hash INTEGER NOT NULL UNIQUE, extended_description TEXT NOT NULL, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE TABLE T_Event (id INTEGER PRIMARY KEY, service_id INTEGER NOT NULL, begin_time INTEGER NOT NULL, duration INTEGER NOT NULL, source_id INTEGER NOT NULL, dvb_event_id INTEGER, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE TABLE T_Data (event_id INTEGER NOT NULL, title_id INTEGER, short_description_id INTEGER, extended_description_id INTEGER, iso_639_language_code TEXT NOT NULL, changed DATETIME NOT NULL DEFAULT current_timestamp);
CREATE INDEX data_title ON T_Data (title_id);
CREATE INDEX data_shortdescr ON T_Data (short_description_id);
CREATE INDEX data_extdescr ON T_Data (extended_description_id);
CREATE INDEX service_sid ON T_Service (sid);
CREATE INDEX event_service_id_begin_time ON T_Event (service_id, begin_time);
CREATE INDEX event_dvb_id ON T_Event (dvb_event_id);
CREATE INDEX data_event_id ON T_Data (event_id);
CREATE TRIGGER tr_on_delete_cascade_t_event                 	AFTER DELETE ON T_Event                     	FOR EACH ROW BEGIN                    	DELETE FROM T_Data WHERE event_id = OLD.id;               	END;
CREATE TRIGGER tr_on_delete_cascade_t_service_t_event               	AFTER DELETE ON T_Service                   	FOR EACH ROW BEGIN                    	DELETE FROM T_Event WHERE service_id = OLD.id;                    	END;
CREATE TRIGGER tr_on_delete_cascade_t_data_t_title                  	AFTER DELETE ON T_Data              	FOR EACH ROW                	WHEN ((SELECT event_id FROM T_Data WHERE title_id = OLD.title_id LIMIT 1) ISNULL) BEGIN                       	DELETE FROM T_Title WHERE id = OLD.title_id;              	END;
CREATE TRIGGER tr_on_delete_cascade_t_data_t_short_description              	AFTER DELETE ON T_Data              	FOR EACH ROW                	WHEN ((SELECT event_id FROM T_Data WHERE short_description_id = OLD.short_description_id LIMIT 1) ISNULL) BEGIN                       	DELETE FROM T_Short_Description WHERE id = OLD.short_description_id;              	END;
CREATE TRIGGER tr_on_delete_cascade_t_data_t_extended_description                   	AFTER DELETE ON T_Data              	FOR EACH ROW                	WHEN ((SELECT event_id FROM T_Data WHERE extended_description_id = OLD.extended_description_id LIMIT 1) ISNULL) BEGIN                 	DELETE FROM T_Extended_Description WHERE id = OLD.extended_description_id;                	END;
CREATE TRIGGER tr_on_update_cascade_t_data                  	AFTER UPDATE ON T_Data              	FOR EACH ROW                	WHEN (OLD.title_id <> NEW.title_id AND ((SELECT event_id FROM T_Data WHERE title_id = OLD.title_id LIMIT 1) ISNULL)) BEGIN                    	DELETE FROM T_Title WHERE id = OLD.title_id;              	END;
sqlite>

Die Indexe sind für die Performance beim selektieren, die sind mir mal egal, die Trigger sind aber schon interessant, weil wenn es so wie beim epg.dat funktionieren soll (wo ja auch ein neues erstellt wird) muss ich ja alle daten von epg events eines senders wo epg daten geladen werden löschen bevor ich die externen epg daten reinschieben kann - sonst gibt es ja doubletten.

Aber zuerst brauchen wir mal id, weil das der primary key in allen tabellen ist .... wobei in meinem SQL Kurs würden jetzt jemand brüllen warum ist das nicht eine einzige Tabelle sondern 7 mit selbem key ... aber ich sagte ja schon das Ghost wohl pragmatisch war als er die DB designed hat.