Bitte einpacken und ins Dorf der unbeugsamen Gallier senden, sobald sie angekommen ist mache ich mich an die Arbeit ...
Frage zur neuen EPG- Datenbank
-
-
DIe Hoffnung stirbt zuletzt.
-
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.
-
zuerst mal danke,
wollte meinen beitrag leisten als tester
aber das ist nicht das crossepg-plugin
die aktuelle version wie die von sin fürs OE2.0 gemacht ist: http://www.i-have-a-dreambox.c…hread.php?threadid=174846
-
Was ist jetzt der Unterschied zwischen GrossEPG und XMLTV? CrossEPG bezieht die Daten vom Sat und XMLTV aus dem Netz?
-
crossepg kann auch xml-daten laden (glaube sogar dieselben resourcen wie beim xmltv)
diese xml-daten werde oft von webseiten "gegrabbed", und da gibt es regelmässig änderungen, und muss dann korrigiert werden (ähnlich wie beim mediaportal und andere plugins die sachen von webseiten verwenden)crossepg bietet auch "OpenTV" ams resource, zum beispiel für 28.2° (UK sender), da wird dann auf 1 bestimmtes "daten-kanal" gezapt wo über den DVB-stream alle EPG daten für die UK kanäle auf 1 mal runtergeladen werden und dann (bei < OE2.2) diese daten in die "EPG.dat" importiert
diese daten sind gut gepflegt und das funktioniert sehr gut (werden auch von provider auf andere receiver verwendet), und eigentlich ist das konzept recht gut (kein zappen auf x sender notwendig, nur kurz auf diesen einen kanal)
daneben werden mit crossepg auch "xepgdb" (hoffe dat stimmt jetzt :P) resourcen angeboten, das sind "epg.dat" dateien die runtergeladen werden
quasi ain epg-backup das mann runterladen und einspielen kanncrossepg is so ein bisschen die "eierlegende-wolmilchsau" für EPG wenn die sender das nicht mitsenden (was öfters der fall ist für nicht-19.2° positionenen - auch DBV-T/C)
daher fühlen ausländische anwender sich immer ein bisschen vernachlässigt wenn das nicht funktioniert (dasselbe thema gab es ja bei OE2.0 auch)
ps:
hatte selbst schon "5 zeilen" im crossepg geändert, komme da aber nicht weiter, und mir fehlt auch die zeit um da wirklich ein zu steigen (im moment so im schnitt 60-stunden arbeitswochen)
testen, mithelfen, dokumentieren kann / werde ich bei so eine sache sicher machen (auch wenns nicht täglich ist) -
öh ja ähmmm DANKE!! Sollte übrigens nicht als jammern aufgefasst werden. War nur so als blöde Frage gemeint. Da Ich leider NULL Ahnung von programmieren habe war mir auch überhaupt nicht klar ob dies schwierig oder einfach ist.
Bezüglich der Anmerkung von bschaar kann Ich zustimmen. Die Open TV Daten sind natürlich besser als xmltv, da direkt vom Transponder geladen und aktueller. Aber das wäre dann der nächste Schritt.
-
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 -
wollte keine diskussion lostreten weder betteln
war halt meine meinung dazu, und das xmltv hab ich lange her verwendet, und kenne die beschränkungen (womit ich nicht gesagt habe das es nur nachteile gibt), da investiere ich keine zeit
ps:
und "schwer" ist relativ -
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.
-
na ja, ich mache im leben lieber was um andere leute zu helfen als zu ärgern
(und hilfeangebot auf die sachen die ich "einfach" finde - und auch recht gut kann - steht noch immer falls mal jemand das angeht)
EDIT
und ich habe damals auch über ein jahr die BBCi-xml datei zur verfügung gestellt, ich kenne daher die thematik -
Ich bin auch für alles dankbar. Egal welche Datenquelle. Viel diskutieren müssen wir da auch nicht. Wenn Ich helfen könnte würd Ichs sofort tun. Da bin Ich aber leider komplett der falsche. PC's zusammenbauen usw. no problemo aber sowas...
-
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.
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:
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.
-
Zitat
ap-get install sqlite3+t
-
Ja das t hilft, aber hier ist der output vom schema:
Code
Alles anzeigensqlite3 /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.
-
das sieht recht logisch aus