Frage zur neuen EPG- Datenbank


    das sollte sein id:sid:tsid:onid:dvbnamespace:timestamp


    Vergleicht man das mit dem Anfang der lamedb:


    wenn ich mich recht erinnere ist sie sid in der serviceref in hex, nehme ich also die erste Zeile mit 11150 ist das in hex 2b8e


    mache ich damit ein grep auf die lamedb gibt es das


    2b8e:00c00000:03f2:0001:25:0


    Und die zeilen sehen so aus wenn man an der stelle in die lamedb reinsieht:


    2b8e:00c00000:03f2:0001:25:0
    3sat HD



    Dann müsste das also die id von 3SAD HD die 1 sein.


    dannn müsste man doch mit einem select und einer where clause mit dieser id die EPG daten aus T_Short_Description kriegen ?


    Kann das wer ausprobieren und bestätigen, weil wie schonn gesagt ohne richtige id kann ich keine inserts in die Tabellen machen.


    Aber ich werde das Problem mal vereinfachen - ich lösche die epg.db und starte nur auf einem Transponder das enigma2, dann kann ich auch nur von maximal einer handvoll EPD Daten in der epg.db kriegen und es müsste einfacher sein rauszufinden wie die zusammenhängen ... mal sehen - echte Doku wäre nett, aber ich glaube DMM hat die für irgendwann mal versprochen :face_with_rolling_eyes:


    EDIT - ja so geht es:


    auf Pro7 geschaltet und gestartet mit vorher entleerter EPG Datenbank, schon sieht es so aus:


    Rechne ich die erste SID 17500 in hex um kommt 445c raus und in der lamedb findet man das:


    Voiala - das sind die Sender de pro7/SAT1 Transponders.


    Was aber heisst das die epgd keine fixen ids hat sondern diese nach first come first serve vergeben werden ... auch gut und eigentlich logisch für die performance das zuerst geschaute an den Anfang zu tun und das selten geschaute immer weiter hintern anzuhängen.


    Also können wir jetzt aus SIDs epg.db ids machen indem wir einfach die hex werte zu integer machen und in der T_Service nachsehen, was uns dann eigentlich alles nötiige für die inserst in die anderne Tabellen liefern sollte.


    Schauen wir uns also diese an was wir brauchen

    5 Mal editiert, zuletzt von Lost in Translation ()

    auch dort brauchst du die id des senders, und ja die T_Event sieht ja so aus:


    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);



    select * from T_Event whwew id=1;


    das liefert das:


    select * from T_Event where id = 1;
    1|1|1417634037|8203|1|8506|2014-12-03 20:46:47


    das 1417634037 müsste dann die begin time sein - in UTC


    Der Timestamp 1417634037 entspricht dem 03.12.2014 um 20:13:57 Uhr


    Auf SAT 1 läuft gerade das grosse backen und das dauert 136min was wenn man es in Sekunden umrechnen 8160 wären, die 8203 könnten also schon stimmen wenn SAT 2 will das wir ein bisschen Werbung mit aufnehmen sollen.


    Das kann man jetzt mit selects auch selber rausfinden:


    select * from T_Title where id = 1;
    1|-908361321|Das große Backen|2014-12-03 20:46:47
    sqlite> select * from T_Short_Description where id = 1;
    1|-629707430|Dokutainment, D|2014-12-03 20:46:47
    sqlite> select * from T_Extended_Description where id = 1;
    1|-1418862024|Moderation: Enie van de Meiklokjes


    Es wird schokoladig! Der perfekte Schokokuchen ist gar nicht so leicht herzustellen - schließlich steht und fällt der Genuss mit der gekonnten Verarbeitung der Grundzutat. Wer hat ein Händchen für den zarten Schmelz? Andrea fordert die Hobby-Bäcker anschließend mit einem Savarin heraus. Der Clou an der Napfkuchenspezialität ist der gerührte Hefeteig, der viel Expertise erfordert. Abschließend ist Geschicklichkeit gefragt: eine Torte aus schiefen Böden muss gestaltet werden!


    Jury: Andrea Schirmaier-Huber, Christian Hümbs|2014-12-03 20:46:47

    Ich habs gerade reineditiert :grinning_squinting_face:


    Wobei wie man die hashes macht hat Ghost weiter unten beantwortet - und ich habe es mal reingeprogged in einer r3 das auch die hashes ausgegeben werden können.


    Aber im Moment verstehe ich noch nicht wie sortieren sich die Folgevents ein ... wir werden es schon rausfinden ...

    Einmal editiert, zuletzt von Lost in Translation ()

    wenn ich das richtig sehe werden auch die now/next daten gespeichert


    warscheinlich auch so lange wie eingestellt in die experteneinstellung (EPG aus die vergangenheit x behalten - oder wie das heist auf deutsch)


    und das mit dem hash muss ich nochmal lesen, weil das hab ich noch nicht geraft



    EDIT
    ich hab noch now/next daten vom 20. November
    da wird nicht aufgeräumt?

    Na ja aber das ist keine Wissenschaft, nur mühsam und wie ich schon sagte solange man nur einen Transponder einer ÖR Sendeanstalt einliest wo du EPG Daten für eine handvoll sender für mehrere Tage hast müsste es leicht sein rauszufinden wie die Daten in die DB gestopft werden müssen,


    Die Daten die das Pluin liefert sind ja eh schon fast Mund bzw. DB gerecht, also start zeit in UTC, duration das haben wir bereits 1:1, ich schreibe mal das Plugin schnell um das es die SID in dezimal ausspuckt, und machen ein select auf T_Service um mir die id ausgeben zu lassen die ich dann in folge für die inserst brauche - schöner test ob das sqllite funktioniert.


    Eines nach dem anderen ...


    EDIT: ich glaube Ghost oder Reichi hat mal geschrieben das sie das alte EPG daten aufräumen regelmässig anstossen wenn neues kommt (das muss mit den Triggern zu tun haben die machen ja deletes), aber ich kann mich auch irren.


    Kannst ja weiter suchen wo die ganzen folge EPG daten sind mit Info und Gelb hast du ja die Liste auf deim sender und ich habe jetzt ja geschrieben wie man sich die ID zum sender holen kann um das where id = für die selects zu haben.

    Zum verstehen ist das OK, ich brauche nur fürs proggen nachher das nackte SQL statement :loudly_crying_face:

    also meine Hemmschwelle mich zu blamieren ist dabei sowas von gering - vor allem wenn sich Wissende zurücklehnen

    ich werde ja selbst auch mal basteln, (EPG short description in die long kopieren, weil die wird bei unser DVB-T "falsch" gesendet), aber ich kann das nicht "user tauglich" machen


    auf jedenfall heute schon wieder etwas dazu gelernt, n8

    Ich lerne das auch gerade erst wieder neu, aber das wissen was wir jetzt haben kann ich auch schon ausproggen, sprich sid aus service ref hole und damit id aus tabelle.


    Dafür muss ich nur eine Viertel Seite Code schreiben ... was zu schaffen ist. Das beinhaltet aber dann schon Database connect und select ausführen, das Insert ist dann leicht - wenn ich den richtigen sql befehl dafür habe und alle nötigen Werte.


    Das ist wie Kraken töten ... einen Arm nach dem anderen abhacken ...


    EDIT: Ich teste gerade, scheint zu funktionieren, aber nachdem die id nur für sender da sind wo es schon EPG Daten gibt müssen wir auch code schreiben der bei neuen Sendern wo es noch gar keine id gibt weil noch gar keine EPG Daten exisiteren in die T_Service auch NEUE Einträge macht ... na ja aber wenn im ersten Schritt die EPG Daten der Sender wo man schon was hat ergänzt werden ist das auch nicht so schlecht, man kann nicht immer alles sofort haben.

    Einmal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Hi,


    die hashes auf den strings haben wir damit man schneller nach texten suchen kann, und damit das einfügen der daten nicht so lange dauert.


    Die alternative wäre gewesen die sqlite volltextsuche zu verwenden.. dafür bräuchte man dann aber einen index auf den text spalten. Was die Datenbank sehr langsam macht.. und riesig.


    Deshalb haben wir uns entschieden einen eigenen kleinen schnellen string hasher zu verwenden. Die hashes kann man über eEPGCache.getStringHash(text) bekommen. Der Algo dahinter ist der sog. MurmurHash3_x86_32 (Murmur3A).


    Findet man in google für alle möglichen programmiersprachen. Der Hash Seed ist 0xbeefbeef.


    Hier mal ein Beispiel wie man die Daten für einen bestimmten Sender aus der DB abfragen würde:

    SQL
    SELECT T_Data.ROWID AS data_id, event_id, source_id, begin_time, duration, dvb_event_id, title, short_description, extended_description, iso_639_language_code FROM T_Data INNER JOIN T_Event ON T_Event.id=T_Data.event_id INNER JOIN T_Service ON T_Service.id=T_Event.service_id LEFT JOIN T_Title ON T_Data.title_id=T_Title.id LEFT JOIN T_Short_Description ON T_Data.short_description_id=T_Short_Description.id LEFT JOIN T_Extended_Description ON T_Data.extended_description_id=T_Extended_Description.id WHERE sid=? AND tsid=? AND onid=? AND dvbnamespace=?;


    Die Haupttabelle ist die T_Event... danach kommen die T_Data einträge die die jewiligen title/short/extended description verbinden. .. eigentlich ist der aufbau recht logisch und selbsterklärend.


    Ansonsten einfach fragen.


    cya

    Beim inserten muss ich die hashes also auch erstellen,.. na gut das werden wir auch noch schaffen.


    Im Anhang ist eine r2 die wenigstens mal für die gefunden Sender aus der lamedb wo es zu importierende EPG daten gibt mit der sid aus der serviceref die id in der epg.db sucht und diese und die in den xml gefundenen descriptions und Zeiten ausgibt.


    Damit müsste die updateEPGDatabase routine in der epgdat.py der Plugins jetzt eigentlich alles haben um es mit sql inserts auch in die epg.db Tabellen zu stopfen,
    ein bisschen Hilfe wäre dabei aber schön, weil sonst müssen wir das mit Trial and error mühsam rausfinden Tabelle für Tabelle.


    PS: Im Moment war mir die Performance noch ziemlich egal, es wird also bei jedem Aufruf die DB neu connected und wieder geclosed beim Verlassen, aber eines nach dem anderen ...


    EDIT: Wenn das SQL Statement dem entspricht was auch enigma2 macht, dann müsste wenn ein event komplett richtig eingetragen ist das select auch wieder alles liefern ... na gut ... das ist eine gewisse Herausforderung :smiling_face_with_sunglasses:


    LG
    gutemine

    Einmal editiert, zuletzt von Lost in Translation ()

    Ich habe noch schnell eine r3 gemacht wo von den descriptions auch mit der genannten routine der hash ermittelt und ausgegeben wird.


    Ich hoffe jetzt haben wir alle daten zusammen für die inserts ... also id für alle tabellen, die rohdaten wie anfang/dauer und lange/kurze beschreibung sowie eben die hash bei den beschreibungen.


    Jetzt geht die Quälerei eigentlich erst los ...


    Aber SQL wissende user könntet mit den Daten die es jetzt in telnet ausgibt auch mit sql insert von hand die Tabellen aktualisieren und schauen ob Ihr damit was produzieren könnt das im EPG auf Info auch angezeigt wird wenn man mit der epg.db dann enigma2 startet :face_with_rolling_eyes:


    LG
    gutemine

    Einmal editiert, zuletzt von Lost in Translation ()

    • Offizieller Beitrag

    Hi,


    in einem statement wird man es nicht schaffen daten einzufügen :winking_face:


    Es sind mehrere ...



    Wichtig wäre noch einen eigenen Eintrag in der T_Source Tabelle zu machen... also z.b. "External Data Cross EPG" oder so.. als description... und diese source_id dann in T_Event verwenden.
    Ich muss dann auch noch im c++ teil was ändern, dass dann solche Events nicht angefasst werden bei einem update der EPG Daten von DVB .. momentan würde bei einem zappen auf einen solchen sender das wieder gelöscht werden.
    Das mach ich die Tage...


    cya