Idee: xmltv2vdr-plugin

  • Quote

    Originally posted by Joe_D
    Dann brauchen wir eine Liste der vom xmltv2vdr-plugin bekannter channel-Attribute.


    Brauchen wir doch eh. Zum Lieferumfang des Plugins muss es ne Liste aller Sender mit Normnamen geben.
    Denn an dieser müssen sich die Grabberauthoren orientieren um die Sendernamen passend umzumappen.


    Und liefert ein Grabber einen Sender für den es noch keinen Eintrag in dieser Liste gibt muss er dir (oder dem Verwalter dieser Liste (kann auch das WIKI sein)) das mitteilen damit du die Liste erweiterst.


    Jedenfalls ist das dir einzige Variante die ich mit vorstellen kann wie das funktionieren könnte ohne das der User da im Zweifel (wenn er zwei Grabber nutzt die den selben Namen oder die selbe Nummer für vershciedene Sender verwenden) im Quellcode rumfummeln muss.


    Überlässt du es den Grabbern für neue Sender willkürlich Strings oder Ziffern als Normname festzulegen, dann könnten hier verschiedene Grabber kollidieren (d.h. den selben Normnamen für verschiedene Sender verwenden).


    Quote

    Originally posted by Joe_D
    Die RFC2838-Notation finde ich gar nicht so übel:


    Jup, eindeutig auch wenn Sender in verschiedenen Ländern die selben Namen haben. Und trotzdem leicht lesbar.



    Wobei ich den Sinn nicht sehe das RFC2838 zu nennen, man einigt sich auf ne Schreibweise für nen Sendernamen und setzt das Länderkürzel hinter. Ist jetzt nicht so eine große Sache ;)


    cu

  • Quote

    Original von Joe_D
    Die RFC2838-Notation finde ich gar nicht so übel:

    Code
    1. theater.zdf.de
    2. dokukanal.zdf.de
    3. doku.zdf.de
    4. info.zdf.de


    Um die Verwirrung komplett zu machen wären doch auch

    Code
    1. pro7.prosiebensat1mediaag.de
    2. prosieben.prosiebensat1mediaag.de
    3. sat1.prosiebensat1mediaag.de
    4. kabeleins.prosiebensat1mediaag.de
    5. kabel1.prosiebensat1mediaag.de
    6. neunlive.prosiebensat1mediaag.de
    7. 9live.prosiebensat1mediaag.de
    8. sixx.prosiebensat1mediaag.de


    RFC konform.

    Powered by Point of View ION330 und Mystique SaTiX-S2 Dual
    Geguckt wird auf einem 52PFL5605H/12 per HDMI mit Atmolight Quattro
    Audio optisch per Yamaha RX-V459 auf einem Teufel Concept P
    Non-TV content über XBMC und boblight
    Remote Harmony 525 durch Atric-IR
    Remote und Streaming mit Motorola XOOM und AndroVDR sowie Daroon Player
    Streaming auf ZBOX ID-81 und Desktop per streamdev
    All based on selfbuild OpenenELEC master


    Nebenbei noch ein par andere VDRs

    The post was edited 2 times, last by pinky666 ().

  • Quote

    Originally posted by steffen_b
    http://xmltv.cvs.sourceforge.n…a/channel_ids?view=markup


    Da hast du schonmal 500 Beispiele - ich denke es sollte möglich sein ein Konsens zu finden.


    Die ist doch schon mal gut. Muss man nur ein wenig aufräumen (sind ja einige überflüssige und einige doppelte drin).


    Mir gings ja hauptsächlich darum so eine Liste einmalig fest zu übernehmen und dann manuell weiterzupflegen anstatt lapidar z.B. auf diese zu verlinken (indem man z.B. den Gabberauthoren schwammig sagt sie sollten Namen nach RFC<irgendwas> verwenden).


    Dann haben die Grabber Autoren feste einndeutige Vorgaben und man kann ohne Konfigurationsfummelei einfach so Grabber installieren und auch problemlos mehrere parallel nutzen.
    So wie ich das sehe sollte man es hinbekommen das man nen Grabber per apt-get (oder wie auch immer) installiert und er ohne weitere Konfiguration (abgesehen von Username/passwort bei Pay Diensten) sofort läuft.


    cu

  • So, ich habe nun mal eine (noch nicht ganz fertige) EPG-Datenquelle gebastelt. Die Frage ist nun, wie diese mit dem Plugin in Verbindung tritt.


    Meine Idee ist nun, das alle Quellen in einem festgelegten Verzeichnis (/var/lib/epgsources) Ihre Listen der zur Verfügung stehenden Sender ablegen. Dabei sollte die Datei genauso heissen wie das Skript/Programm. Desweiteren muss die Datei (und das ganze Verzeichnis) Schreibrechte für die Gruppe vdr haben.


    Die Datei könnte folgenden Aufbau haben:

    Code
    1. pipe,plugin,00:00
    2. ard.de,001
    3. *zdf.de,002


    In der ersten Zeile (bzw. erste Zeile ohne #) steht die Ausführungsart: pipe oder file, ob das Skript vom vdr ausgeführt werden soll (plugin, standalone - bei pipe zwingend plugin) und die Aktualisierungszeit der Datenquelle in Lokalzeit (wenn bekannt)


    Wenn Dateien geschrieben werden müssen diese auch irgendwie gefunden werden. Deshalb sollten diese dann genauso wie die Quelle mit der Extension xmltv heissen und auch im epgsources-Verzeichnis landen.


    Gruß


    Joe_D

  • Ich fange jetzt mal mit der Senderliste an, bei denen ich EPG-Informationen (meist nur Kurztext, d.h. Serientitel) brauche:


    Code
    1. rtl.de
    2. sat1.de
    3. prosieben.de
    4. kabel1.de
    5. rtl2.de
    6. vox.de
    7. das-vierte.de
    8. tele5.de
    9. superrtl.de


    Die Rückgabewerte des Skripts müssen auch festgelegt werden:


    Code
    1. 0=Alles OK
    2. 1=allgemeiner Fehler (z.B. out of memory,...)
    3. 2=temporärer Fehler (z.B. connection failed, ...)


    Auf stderr kann im Fehlerfall eine Meldung ausgegeben werden. Auf stdout muss bei pipe die xmltv-Ausgabe erfolgen. Bei Dateiausgabe muss die Ausgabe ins /var/lib/epgsources-Verzeichnis erfolgen, der Name der xmltv-Datei muss dabei der gleiche sein wie das Skript, mit Extension .xmltv, also z.B. hoerzu.xmltv


    Ich bin noch am Überlegen, ob es überhaupt Sinn macht für mehr als einen Tag im Vorraus EPG-Daten einzulesen. Nach dem Einlesen sind die EPG-Einträge als gesperrt markiert (geht nicht anders), werden also vom Sender-EPG nicht mehr verändert. Einige Sender liefern Beschreibungen erst sehr spät, eine Sperrung würde dazu führen das Sendungen ohne Beschreibung aufgenommen werden (im Falle, das z.B. nur der Serientitel hinzugefügt wird).


    Gruß


    Joe_D

  • steffen_b


    Vom plain VDR wird aber gar kein externes EPG ohne Mischen (=TableID existierender Events auf 0 setzen) unterstützt. CLRE sorgt nur dafür, das das aktuelle EPG gelöscht wird und sogleich mit dem Sender-EPG wieder befüllt wird. Das zu verhindern geht IMHO nur mit so Krücken wie dem noEPG-Patch.


    Mehr als 1 Tag im Vorraus macht nur Sinn wenn der User dafür sorgt, das sein VDR das Sender-EPG daran hindert geladen zu werden (d.h. xmltv2vdr bräuchte dann noEPG-Unterstützung).


    Die Anzahl der zur Verfügung stehenden Tage kann man in die erste Zeile packen, hinter der Aktualisierungszeit:


    Code
    1. pipe;plugin;00:00;18
    2. 4
    3. *zdf.de,002

    In die zweite Zeile würde ich demnach die Anzahl der Tage schreiben, die vom xmltv2vdr-Plugin angefordert wurden.


    Gruß


    Joe_D

  • @Mreimer


    Quote

    Was bewirkt eigentlich der SVDRP-Befehl "PUTE"?

    Der Befehl lädt eine Datei im Format der epg.data in die internen Schedules/Event-Strukturen.


    Quote

    Kann man damit mit VDR-Bordmitteln einen EPG-Eintrag überschreiben *und* sperren?

    IMHO Nein. Die Einträge werden nur hinzugeladen.


    Dazu kommt noch: Man kann zwar die TableID auf 0 setzen, aber wenn man nicht die gleiche EventID und Version des Events verwendet wie vom Sender geliefert wird vom VDR nochmals ein Event angelegt. Dann hat man zwei Einträge.


    Bei CLRE kommt noch dazu: Wenn man einen einzelnen Kanal löschen möchte wird intern "nur" ein Cleanup ausgeführt. Wenn ein Timer existiert wird der zugehörige Event nicht gelöscht. Darüber bekommt man aber keine Infos (das der Kanal nicht komplett gesäubert wurde).


    Bei CLRE ohne Argument hingegen werden die Timer von den Events entkoppelt und das komplette EPG gelöscht. Nach 10 Sekunden wird es dann wieder vom VDR gefüllt.


    Gruß


    Joe_D

  • Ich überschreibe (geänderter Subtitle und geänderte Beschreibung) und sperre ständig EPG Einträge mittels svdrp per pute (macht bei mir epgsearch in Verbindung mit dem VDRSeriesTimer generell für alle Suchtimer), und so wie ich das sehe funktioniert das.


    BTW: EPG mit mehr als einen Tag macht durchaus Sinn wenn man das Senderepg per noEPG sperrt. Das mache ich momentan für einige Sender per tvm2vdr Plugin.
    Da wird halt vorher das EPG des Senders gelöscht und komplett das 7 Tage EPG neu importiert.


    BTW2: Deine internen Betrachtungen sind interessant, ich hatte schon länger die Vermutung das der VDR beim EPG Import per svdrp einige kleine Bugs hat. Aber wie gesagt, rein praktisch funktioniert das bei mit trotzdem.


    cu

  • Keine_Ahnung


    Quote

    Ich überschreibe (geänderter Subtitle und geänderte Beschreibung) und sperre ständig EPG Einträge mittels svdrp per pute (macht bei mir epgsearch in Verbindung mit dem VDRSeriesTimer generell für alle Suchtimer), und so wie ich das sehe funktioniert das.

    Na klar, wenn epgsearch die EventID ausliest, den Event verändert und mit gleicher EventID per PUTE wieder einliest gibts dabei gar kein Problem!


    Hier der entsprechende Abschnitt aus dem VDR-Source der das Sender-EPG einpflegt:

    Am Anfang wid ein Event entweder per ID vom Sender [SiEitEvent.getEventId()] oder der exakten (!) StartTime vom Sender gesucht (Zeile 68). Wenn beide Informationen nicht vorhanden sind wird ein neues Event angelegt (Zeile 74). Bei externen Quellen hat man ja meistens nicht die exakte ID oder die exakte Startzeit (ist z.B. um 5 Minuten verschoben - habe ich bei infosatepg-Daten oft gehabt!) - dann wird vom VDR noch ein Event dazu angelegt und schon hat man doppelte Einträge ;)


    Wenn man aber das EPG vorher ausliest und nur Subtitle oder Description ändert und die TableID dann auf 0 setzt ist man auf der sicheren Seite (Zeile 83ff).


    Gruß


    Joe_D

  • Quote

    Originally posted by Joe_D
    Na klar, wenn epgsearch die EventID ausliest, den Event verändert und mit gleicher EventID per PUTE wieder einliest gibts dabei gar kein Problem!


    Ah, dann hatte ich das falsch verstanden. Ich lese ja nur den Event aus, modifiziere ihn und schreibe ihn gleich wieder zurück.
    Und das ist ja AFAIK auch die einzige Methode für so was, auch wenns ums mischen des EPG mit externen Infos geht.


    Quote

    Originally posted by Joe_D
    Bei externen Quellen hat man ja meistens nicht die exakte ID oder die exakte Startzeit (ist z.B. um 5 Minuten verschoben - habe ich bei infosatepg-Daten oft gehabt!) - dann wird vom VDR noch ein Event dazu angelegt und schon hat man doppelte Einträge ;)


    Klar, klingt logisch :)



    Das ist auch der Grund warum ich bisher noch nie so was wie xmltv2vdr (inkl. mischen) per Script programmiert hatte (C und Plugins programmieren ist nicht mein Fall), das ganze svdrp gefummel (komplettes epg holen, mischen udn zurückschreiben) reist den VDR in den tot. Das ist schon besser in einem richtigen Plugin aufgehoben. svdrp ist da irgendwie ne Krücke.


    cu

  • svdrp pute filename oder das übergeben im Plugin macht genau 0 Unterschied. Das einlesen des epg sollte in kleineren Häppchen passieren ansonsten reisst es den vdr in den Tod (bzw der watchdog schlägt zu).


    Wäre es nicht sinnvoll wenn man das mergen und das Einfügen in die internen VDR Strukturen intelligenter gestalten könnte ? - Anyway ich denke nicht das ich das Ziel/den Umfang verstehe den das Plugin erfüllen soll. Andererseits ist das was ich denke ohne Patchorgien nicht realisierbar. Keine Ahnung ...

  • Quote

    Original von steffen_b
    svdrp pute filename oder das übergeben im Plugin macht genau 0 Unterschied.


    Ebend nicht, SVDRP erlaubt nicht gleichzeitig mehere Verbindungen, deswegen blockiert massiver EPG Kram über SVDRP andere Dinge.
    Dasa weiss ich nämlich weil es bei mir täglich der Fall ist ;)


    Quote

    Original von steffen_b
    Das einlesen des epg sollte in kleineren Häppchen passieren ansonsten reisst es den vdr in den Tod (bzw der watchdog schlägt zu).


    Ebend, alles gemurkse.


    Quote

    Original von steffen_b
    Wäre es nicht sinnvoll wenn man das mergen und das Einfügen in die internen VDR Strukturen intelligenter gestalten könnte ?


    Das ist ja der Grundgedanke hinter diesen Plugin ;)


    Quote

    Original von steffen_b
    Andererseits ist das was ich denke ohne Patchorgien nicht realisierbar. Keine Ahnung ...


    Das was dieses Plugin machen soll, das macht das infosatepg Plugin schon lange. Ich habe das also keine Angst um die Realisierbarkeit ;)


    cu

  • Wenn ich mal aus Sicht eines potentiellen Grabber Authors und epgdata2vdr Benutzers ;) schreibe:


    Ich weiss nicht wieviele Tage im voraus die Daten gehen - normalerweise 18 Tage, es wird halt geladen was verfügbar ist. Wenn ich neu lade werden alle Daten neu geladen, für die 18 Tage. Ich muss pro Tag laden da der VDR deutlich länger zum laden braucht als ich zum Parsen und erstellen der Daten (sprich der watchdog schlägt dann zu). Ich hab keine Probleme mit svdrp für einen Tag jeweils. Im Moment benutze ich aber auch svdrpd. Was sich da so hässlich anfühlt ist dass das EPG im Mainthread geladen wird. Das heisst während des Parsens nimmt der VDR keine Tasten entgegen.


    Das Erstellen eines Files pro Sender wäre ein wenig haarig weil ich dann geschätzt 60 (?) Dateien erstellen würde (geht sicher auch irgendwie müsst ich mal grübeln).


    Wenn also der Plan wäre den Grabber per Sender per Tag laufen zu lassen wäre das von der Effizienz das worst-case Szenario für "meinen Grabber".


    Dann müssten die events idealerweise die event id von dem provider bekommen der auch Bilder liefert, damit die Bilder auch funktionieren.

  • steffen_b


    Quote

    Was sich da so hässlich anfühlt ist dass das EPG im Mainthread geladen wird. Das heisst während des Parsens nimmt der VDR keine Tasten entgegen.

    Mach Dir doch keinen Kopf wie ich das in den VDR einlese (und natürlich niemals per svdrp) ;)


    Zur Zeit habe ich einen Grabber, der alle Daten per Pipe überträgt (also keine Dateien). Da sind die Daten aller Sender über alle Tage drin. In meinem Testszenario dauert das Holen der Daten von der EPG-Quelle 3,5 Sekunden - sind aber auch nur 2 Tage und 5 Sender.


    Das Einlesen passiert absolut asynchron in einem eigenem Thread (also nicht im Mainthread), der dort per cPipe den Grabber-Prozess startet und ewig brauchen darf! Da das Einlesen noch nicht fertig programmiert ist, kann ich noch nicht sagen wie lange das wirklich dauert.


    Quote

    Das Erstellen eines Files pro Sender wäre ein wenig haarig weil ich dann geschätzt 60 (?) Dateien erstellen würde (geht sicher auch irgendwie müsst ich mal grübeln).

    Selbst bei Ausgabeziel Datei muss alles in einer Datei drin sein.


    Quote

    Dann müssten die events idealerweise die event id von dem provider bekommen der auch Bilder liefert, damit die Bilder auch funktionieren.

    Ist beim Einslesen ohne Mischen kein Problem. Dafür müsstest Du aber ein neues Attribut erfinden, das man an das programme-Element anhängt (eventid?).


    Gruß


    Joe_D

  • Ich wollte nur klar machen das svdrp hier nicht das problem ist, da eh nur der Dateiname übergeben wird, das Einlesen des VDR hat ein Performanceproblem ... (wenn man es so nennen möchte).


    Das letzte mal als ich es probiert hatte war es bei um 1s+/- pro Tag mit ca 60 Sendern.


    Ok wäre auf jedenfall einen Versuch wert :) ...


    Solange du das dann einliest ;)

  • Quote

    Original von steffen_b
    Ich wollte nur klar machen das svdrp hier nicht das problem ist, da eh nur der Dateiname übergeben wird,


    AFAIK aber im 1.6er nur per extra Patch, im 1.7er ist dann der Patch irgendwie in den VDR gekommen.


    cu

  • Anbei mal ein "Teaser" für die Weihnachtstage ;)


    Meine Testdatei in /var/lib/epgsources sieht so aus:



    Bei Interesse könnt Ihr meine EPG-Quelle per PN haben.


    Bis jetzt geht:

    • Auswahl der xmltv-Kanäle und der Anzahl der Tage, die von der Quelle geholt werden sollen
    • Zuordnung der xmltv-Kanäle zu (mehreren) VDR-Kanälen (mit Prüfung auf Überschneidungen) und Einstellung der Optionen (Hinzufügen/Kurztext/Langtext)
    • Manuelles Update über SVDRP


    Auf der Liste stehen noch:

    • Automatisches Update mit einstellbarer Zeit
    • mehr Optionen und Einstellbarkeit der Optionsnamen (z.B. für Actor, Date, Country)


    Gruß


    Joe_D