Idee: xmltv2vdr-plugin

  • Klasse, da fang ich doch gleich zu spielen an :)


    Kannst du noch was zur Schnittstelle sagen? Weil ich blicke da im Moment nicht so wirklich durch wie du da jetzt die Schnittstelle aufgebaut hast.
    Und dein Grabber läuft bei mit vermutlich nicht (das tvm2vdr Plugin tats auf meinem alten Debian auch nicht), also bastel ich mir da lieber selber einen.


    cu

  • Ist wie hier im Thread beschrieben:


    Es gibt eine Datei in /var/lib/epgsources und ein Programm in z.B. /usr/bin (muss im Pfad liegen).


    Wenn die Source z.B epgdata heisst, dann heisst die Konfigurationsdatei in /var/lib/epgsources auch so und hat z.B. folgenden Aufbau



    Hier stehen alle von der Quelle zur Verfügung gestellten Kanäle drin.


    Die Zahlen in der zweiten Zeile bedeuten Anzahl zu holender Tage (übers Plugin einstellbar) und maximale Anzahl Tage, die diese Quelle bereitstellt.


    Meine Quelle verwendet diese Datei als Konfigurationsdatei (muss man aber nicht), deshalb gibt es hier ein Mapping vom Quellkanal auf den xmltv-Kanal.


    Die ausführbare Datei in /usr/bin muss nun auch epgdata heissen und eine Datei epgdata.xmltv in /var/lib/epgsources erzeugen. Mit einem svdrpsend plug xmltv2vdr updt wird die Datei dann eingelesen.


    Anstatt file kann man auch pipe verwenden, dann wird die EPG-Source direkt aufgerufen und das Ergebnis direkt verwertet.


    Gruß


    Joe_D

  • Zitat

    Originally posted by Joe_D
    Die Zahlen in der zweiten Zeile bedeuten Anzahl zu holender Tage (übers Plugin einstellbar)


    Ah, das hatte mich verwirrt (war nämlich auch meine erste Vermutung), das wird bei mir nämlich garnicht gespeichert. Da steht immer "1" egal was ich im Plugin einstelle.
    Wobei ich jetzt gerade gesehen habe der der Wert in der GUI schon garnicht gespeichert wird. Stelle ich dort etwas ein und gehe aus dem Menü raus, dann steht dort wieder "1" wenn ich diese Einstellungsseite wieder aufrufe. Also vermutlich noch ein kleiner Bug dort.


    Zitat

    Originally posted by Joe_D
    Meine Quelle verwendet diese Datei als Konfigurationsdatei (muss man aber nicht),


    D.h. der zweite Wert kann auch weggelassen werden und es geht auch sowas?


    Und das Plugin liest die gewünschten Kanäle aus seiner Datei unter \\Easyvdr\root\var\lib\epgsources\ (die mit den Stern davor)? Also keine Kommandozeilenparameter?


    Und ist das konfigurierte Mapping über alle Grabber gültig? D.h. wenn ich in einem unter ARD.de das Mapping einstelle, gilt das denn auch automatisch für einen anderen Mapper der einen Kanal namens ARD.de bietet?



    Der Rest ist dann klar, danke.


    cu

  • Keine_Ahnung


    Zitat

    Wobei ich jetzt gerade gesehen habe der der Wert in der GUI schon garnicht gespeichert wird.

    Richtig, das ist noch TODO.


    Zitat

    D.h. der zweite Wert kann auch weggelassen werden und es geht auch sowas?

    Ja, es kann nur sein das Du evtl. einen Strichpunkt dahinter setzen musst..


    Zitat

    Und ist das konfigurierte Mapping über alle Grabber gültig? D.h. wenn ich in einem unter ARD.de das Mapping einstelle, gilt das denn auch automatisch für einen anderen Mapper der einen Kanal namens ARD.de bietet?

    Natürlich. Das war doch der Sinn der Sache, oder nicht? ;)


    Gruß


    Joe_D

  • Beim infosatepg Plugin hatte ich einige Sender (deren EPG ich per noEPG abgeschaltet hatte) für 7 Tage aktualisiert und andere (wo nur der Subtitle eingefügt wurde) nur für einen Tag.
    So wie ich das sehe ist da mit der jetzigen Schnittstelle nicht möglich, hast du diesen Fall bedacht?


    Ferner ist mir nicht klar wie ich die Liste unter /var/lib/epgsources updaten soll. Die Idee ist ja vermutlich das der Grabber beim Aufruf diese Liste einliest und aktualisiert (d.h. neue Sender einfügt und nicht mehr unterstützte entfernt) so das xmltv2vdr mitbekommt wenn sich die Senderliste (d.h. die Sender die der Grabber bereitstellt) ändert, allerdings bekommt das Plugin die Änderungen nur beim Neustart mit. Wie ist das denn gedacht?


    cu

  • Zitat

    So wie ich das sehe ist da mit der jetzigen Schnittstelle nicht möglich, hast du diesen Fall bedacht?

    Nein, aber irgendwie ist es eben auch ziemlich schwierig das alles so unter den Hut zu bekommen.


    Mein Ansatz geht davon aus, das man der Quelle sagen kann wieviele Daten diese zur Verfügung stellen soll, das verkleinert die Datenmenge und beschleunigt den Updateprozess. Wobei eine Quelle auch mehr Daten liefern kann (ist dann aber unnötig).


    Wenn man bei den Kanälen nun auch die Anzahl der Tage angeben kann, muss das Maximum immer die kleinste eingestellte Anzahl Tage aller Quellen sein, oder? (Also Quelle A stellt für ard.de 16 Tage zur Verfügung, eingestellt sind 5, Quelle B stellt für ard.de 7 Tage zur Verfügung, eingestellt sind 7. Dann ist die maximal einstellbare Anzahl der Tage im Kanal 5. Und wenn nun in der Quelle B die Tage auf 3 gestellt werden, müsste bei allen Kanälen die maximale Anzahl der Tage auf 3 abgesenkt werden.


    Ansonsten kann es vorkommen, das eben nicht garantiert die Anzahl Tage eingelesen wird (bei Ausfall von Quellen).


    Oder andersrum, der Max-Wert der Anzahl der Tage in den Kanälen ist das Minimum aller Max-Werte der Anzahl Tage der Quellen ;) Wobei eine Änderung in den Kanälen auf die Anzahl der Tage in den Quellen auswirken würde. Was ist da besser? Eher letzteres, oder?


    Zitat

    Ferner ist mir nicht klar wie ich die Liste unter /var/lib/epgsources updaten soll. Die Idee ist ja vermutlich das der Grabber beim Aufruf diese Liste einliest und aktualisiert

    Ja, wenn er das kann. Mein Grabber macht das (bislang) nicht, d.h. die Liste ist statisch.


    Zitat

    allerdings bekommt das Plugin die Änderungen nur beim Neustart mit. Wie ist das denn gedacht?

    Es ist ja jetzt schon alles so programmiert, das es während der Laufzeit neu eingelesen werden kann. Wird bislang nur bei An- und Abwahl von Quell-Kanälen gemacht.


    Gruß


    Joe_D

  • Zitat

    Originally posted by Joe_D

    Nein, aber irgendwie ist es eben auch ziemlich schwierig das alles so unter den Hut zu bekommen.


    Klar :)


    Zitat

    Originally posted by Joe_D
    Mein Ansatz geht davon aus, das man der Quelle sagen kann wieviele Daten diese zur Verfügung stellen soll, das verkleinert die Datenmenge und beschleunigt den Updateprozess. Wobei eine Quelle auch mehr Daten liefern kann (ist dann aber unnötig).


    Klingt sinnig.


    Zitat

    Originally posted by Joe_D
    Wenn man bei den Kanälen nun auch die Anzahl der Tage angeben kann, muss das Maximum immer die kleinste eingestellte Anzahl Tage aller Quellen sein, oder? (Also Quelle A stellt für ard.de 16 Tage zur Verfügung, eingestellt sind 5, Quelle B stellt für ard.de 7 Tage zur Verfügung, eingestellt sind 7. Dann ist die maximal einstellbare Anzahl der Tage im Kanal 5. Und wenn nun in der Quelle B die Tage auf 3 gestellt werden, müsste bei allen Kanälen die maximale Anzahl der Tage auf 3 abgesenkt werden.


    Ansonsten kann es vorkommen, das eben nicht garantiert die Anzahl Tage eingelesen wird (bei Ausfall von Quellen).


    Ich denke der Anspruch das die Quelle GARANTIERT X liefert (oder das alle Quellen immer was liefern) ist zu hoch. Der Nutzer stellt halt ein was er gerne hätte und alle Grabber liefern davon das max. Mögliche. Mehr geht ja eh nicht, kommt weniger als der Nutzer eingestellt hat dann hat er halt Pech (ist ja bei den bisherigen Lösungen auch nicht anders, stelle ich z.B. im Infosatepg Plugin 7 Tage ein und der SFI liefert gerade nur 3 Tage (wegen Ausfall) dann habe ich halt auch Pech).


    Meinem Verständnis nach ist diese Info (Grabber XY liefert 14 Tage) noch eine rein Informative Schätzung für den Nutzer. Diese Info könnte man hinter dem Grabbernamen in der Liste anzeigen.


    Zitat

    Originally posted by Joe_D
    Oder andersrum, der Max-Wert der Anzahl der Tage in den Kanälen ist das Minimum aller Max-Werte der Anzahl Tage der Quellen ;) Wobei eine Änderung in den Kanälen auf die Anzahl der Tage in den Quellen auswirken würde. Was ist da besser? Eher letzteres, oder?


    Ähm, jein ;)


    Warum das alles nicht einfacher halten?


    Wenn das Plugin von nem Grabber wissen will was er liefern kann, dann fragt er einfach (Aufruf mit dem Parameter --getinfo und der Grabber liefert die Liste seiner Fähigkeiten (file|pipe, geschätzte Tage, unterstützte Sender) auf stdout zurück).



    Wenn das Plugin dann Programminfos will dann fragt es dem Grabber danach (z.B. als Liste per stdin). D.h. z.B. gibt mir Programm A für 2 Tage und Programm B für 14 Tage auf stdout. Und der Grabber liefert was er hat. Hat er weniger Tage dann ist das halt so (kann man dann eh nix dran ändern).


    Zitat

    Originally posted by Joe_D
    Ja, wenn er das kann. Mein Grabber macht das (bislang) nicht, d.h. die Liste ist statisch.


    Naja, bei mir ist sie auch statisch, aber sie liegt in ner CSV Datei (das finde ich schön weggekapselt in ner Datenbank sinniger). Und theoretisch könnte die sich ja per Paketmanager automatisch updaten (ohne das der Nutzer das mitbekommt).
    Ich möchte halt gerne vermeiden das man da wieder in irgendwelchen Dateien rumeditieren muss.


    cu

  • Keine_Ahnung


    Mir geht es nicht darum, das die Quelle garantiert etwas liefert, sondern das die Einstellungen garantiert das ergeben, was man meint einzustellen ;)


    Beispiel:


    Quelle A liefert ard.de maximal 16 Tage, eingestellt 10 Tage
    Quelle B liefert ard.de maximal 7 Tage, eingestellt 7 Tage


    Beim Mapping ard.de auf VDR-Kanal kann man nun nur noch 7 Tage angeben. Könnte man 10 angeben und die Quelle A fällt aus kann Quelle B den Kanal keine 10 Tage füllen (sondern nur noch 7). Der User fragt sich was denn nun schon wieder kaputt sei und ich bekomme eine "Fehlermeldung" ;)


    Zitat

    Wenn das Plugin von nem Grabber wissen will was er liefern kann, dann fragt er einfach

    Nein, ich möchte keinen Datenaustausch oder Protokoll zu den Grabbern. Der Grabber holt Daten und stellt diese bereit, entweder über eine Pipe oder über eine Datei (nach /var/lib/epgsources). In der Config-Datei in /var/lib/epgsources steht was er kann und wie er heisst. Mehr Infos benötigt man IMHO nicht, oder?


    Zitat

    Ich möchte halt gerne vermeiden das man da wieder in irgendwelchen Dateien rumeditieren muss.

    Das verstehe ich jetzt nicht. Wo muss was rumeditiert werden?


    Gruß


    Joe_D

  • Zitat

    Originally posted by Joe_D
    Mir geht es nicht darum, das die Quelle garantiert etwas liefert, sondern das die Einstellungen garantiert das ergeben, was man meint einzustellen ;)


    Das klappt aber leider nicht, denn keine Quelle liefert garantiert das was der User einstellt. Und damit ergibt sich das, was der User einstellt halt nicht immer ;)


    Der User Wünscht und nimmt dann davon das was er bekommt. Es sei denn jemand treibt wirklich ne brauchbare zuverlässige Datenquelle auf, aber daran glaube ich nicht wirklich ;)


    Zitat

    Originally posted by Joe_D
    Quelle A liefert ard.de maximal 16 Tage, eingestellt 10 Tage
    Quelle B liefert ard.de maximal 7 Tage, eingestellt 7 Tage


    Beim Mapping ard.de auf VDR-Kanal kann man nun nur noch 7 Tage angeben. Könnte man 10 angeben und die Quelle A fällt aus kann Quelle B den Kanal keine 10 Tage füllen (sondern nur noch 7). Der User fragt sich was denn nun schon wieder kaputt sei und ich bekomme eine "Fehlermeldung" ;)


    Aber wenn ich 10 Tage einstellen will weil ich dann meistens 10 Tage bekomme, ausser Quelle A fällt mal wieder aus, dann freue ich mich doch trotzdem über die 7 Tage. Da werde ich dich dann doch nicht anmeckern weil mein Grabber versagt ;)



    Abgesehen davon, auch wenn ich in diesem Beispiel 7 Tage einstelle kann es sein das ich nur 3 bekomme. Die Grabber liefern ja nicht GARANTIERT das was sie angeben.
    Wenn eine Quelle ausfällt dann läuft das ja nur noch aus dem Cache. Und dann verringert sich der Wert.



    Wie gesagt, ich betrachte diese Zeiteinstellungen nicht als Garantie für den Datenerhalt sondern eher als Maximalwunsch.


    - Bei den Sendern wo ich Sender EPG mit externen EPG mische (wegen den Serientiteln) will ich max. einen Tag haben.
    - Und bei Sendern wo ich per noEPG das Sender EPG abschalte will ich 14 Tage, ist aber auch nicht Tragisch wenns mal weniger sind weil alle Quellen gerade mal schwächeln.
    Und wenn jetzt der Grabber für 20 Sender das 14 Tage EPG holt obwohl ich nur einen Sender für 14 Tage will und die anderen 19 nur für einen ist das irgendwie etwas ungünstig. Daher die Idee das für jeden Sender zu beschränken.



    Hm, die Sichtweisen scheinen hier ja individuell sehr unterschiedlich zu sein :)


    Wobei man da auch drumherumbasteln kann, dann dupliziert man halt nen Grabber und stellt den einmal für einen Tag ein und die Kopie für 14 Tage. Ist halt ne Diskussion um Feinheiten.


    Zitat

    Originally posted by Joe_D
    Nein, ich möchte keinen Datenaustausch oder Protokoll zu den Grabbern. Der Grabber holt Daten und stellt diese bereit, entweder über eine Pipe oder über eine Datei (nach /var/lib/epgsources). In der Config-Datei in /var/lib/epgsources steht was er kann und wie er heisst. Mehr Infos benötigt man IMHO nicht, oder?


    Das passt ja im Prinzip schon, ist ja auch egal ob über ne Pipe oder über diese Datei.


    Nur das diese Datei auch gleichzeitig die Konfig fürs Plugin ist macht das IMHO etwas unsauber.
    Wobei man damit natürlich auch leben kann, dann liest man sie halt vor dem schreiben ein, parst die settings und trägt die in der neu erstellten wieder ein.


    Zitat

    Originally posted by Joe_D
    Das verstehe ich jetzt nicht. Wo muss was rumeditiert werden?


    Bei deinem Ansatz die /var/lib/epgsources auch als Plugin Setting und als Mapping Config zu nehmen, sowas will ich halt vermeiden. Deswegen betrachte ich die Sache evtl. auch irgendwie anderst.


    cu

  • Zitat

    Bei deinem Ansatz die /var/lib/epgsources auch als Plugin Setting und als Mapping Config zu nehmen, sowas will ich halt vermeiden. Deswegen betrachte ich die Sache evtl. auch irgendwie anderst.

    Nein, in /var/lib/epgsources liegt die Configdatei des Grabbers und dort wird vom Plugin nur angewählt wieviele Tage und welcher Kanal vom Grabber geholt werden sollen.


    Ein Grabber kann sowas aber auch total ignorieren und einfach irgendwas holen (z.B. 60 Kanäle mit 16 Tage). In der Einleseroutine wird dann nur das eingelesen, was auch im Plugin angewählt wurde.


    Die Config vom Plugin liegt in der setup.conf, dort steht welcher Grabberkanal auf welchen VDR Kanal gemappt wird und dort stehen auch die Flags, was von den Grabberkanälen verwendet werden soll.


    Es existiert sehr wohl eine geradlinige Trennung zwischen Plugin und Grabber. Einzige Schnittstelle ist die Configdatei des Grabbers.


    Wenn projects.vdr-developers.org wieder geht werde ich dort ein neues Projekt aufmachen.


    Gruß


    Joe_D

  • Wobei schon auffällt das noch nie ein tv-browser Grabber gesichtet wurde, obwohl es technisch sehr einfach wäre diese Daten zu nutzen (ist ja Java Open Source, ist also kein Geheimnis wie man an die Daten kommt).
    Also besser die Finger davon weglassen. Das würde dem tv-browser Projekt vermutlich sehr schaden wenn so was auftauchen würde.


    cu

  • Wie ist denn eigentlich die korrekte Abwicklung von Sendern gedacht die sich einen Sendeplatz teilen? Z.B. Nick/Comedy, das betrachtet tvm ja als zwei Sender.


    Hast du da eine Vorgabe wie sich Grabber verhalten sollten?
    Das einfachste wäre ja währen der xml Ausgabe den Sendernamen anzupassen (also aus der Sender ID "nick.de und "comedy.de" die Sender ID "nick/comedy.de" zu machen), dann muss nicht das gesamte XML im Speicher gehalten zu werden.
    Aber dann sind die Sendungen nicht zeitlich sortiert, und AFAIK mag der VDR es nicht wenn die unsortiert in den Speicher geschrieben werden (IIRC gabs bei ifosatepg das Problem).


    cu

  • Keine_Ahnung


    Zitat

    Wie ist denn eigentlich die korrekte Abwicklung von Sendern gedacht die sich einen Sendeplatz teilen? Z.B. Nick/Comedy, das betrachtet tvm ja als zwei Sender.

    Der Sender heisst dann bei uns nickcomedy.de und der Grabber muss die Daten der "zwei Sender" richtig von 00:00-23:59 in die xmltv eintragen.


    Problematisch sind nur die "Sendeschluss-Sendungen", z.B. bei "ComedyCentral" und bei "Nickelodeon" die müssten herausgefiltert werden.


    Kann ich mal in meinem Grabber ausprobieren...


    Gruß


    Joe_D

  • Zitat

    Originally posted by Joe_D
    Problematisch sind nur die "Sendeschluss-Sendungen", z.B. bei "ComedyCentral" und bei "Nickelodeon" die müssten herausgefiltert werden.


    Das geht ja einfach.


    Ich sehe halt nur das Problem mit dem Sortieren, das macht dann ja den ganzen schönen schlanken SAX Parser Ansatz kaputt.
    Oder ist das doch kein Problem wenn die Sendungen im XML nicht sortiert sind?


    cu

  • Zitat

    Oder ist das doch kein Problem wenn die Sendungen im XML nicht sortiert sind?

    Solange eine stop-Angabe in der xmltv drin steht ist es vollkommen egal wie es in der xmltv drin steht.


    Nur wenn keine stop-Angabe vorhanden ist muss alles hintereinander stehen, da VDR intern eine Aufnahmelänge benötigt (und die bekommt man nur durch die start-stop-Angabe). Im xmltv-Standard darf man stop weglassen, aber das berücksichtige ich gerade (noch) nicht.


    Desweiteren mache ich noch keinen Check auf Überlappungen etc. pp. (beim Anfügen von Events). Ist sowieso die Frage wie man sowas behandeln soll, d.h. ein Event das 5 Stunden lang ist, danach kommen 4 Events die in den 5 Stunden reinpassen. Aber da ist ja schon das Event mit den 5 Stunden drin??


    Gruß


    Joe_D

  • Zitat

    Originally posted by Joe_D

    Solange eine stop-Angabe in der xmltv drin steht ist es vollkommen egal wie es in der xmltv drin steht.


    Das hört sich doch schon mal gut an.


    Zitat

    Originally posted by Joe_D
    Desweiteren mache ich noch keinen Check auf Überlappungen etc. pp. (beim Anfügen von Events). Ist sowieso die Frage wie man sowas behandeln soll, d.h. ein Event das 5 Stunden lang ist, danach kommen 4 Events die in den 5 Stunden reinpassen. Aber da ist ja schon das Event mit den 5 Stunden drin??


    Längerfristig wäre es natürlich toll wenn das Plugin mit jeder validen XMLTV XML Datei zurechtkäme.
    Aber das kann ja unendlich komplex werden (verschiedene Sprachversionen, verschiedene Epsisodennummerierungsarten usw.). Da ist es IMHO OK wenn das Plugin einfach bestimmte Dinge voraussetzt die vom Grabber erfüllt werden müssen und die Verarbeitung abbricht wenn es feststellt das dem nicht so ist.
    Und ich denke für den Anfang sollte es reichen wenn gefordert wird das es keine überlappenden Einträge geben darf.



    Wasaber generell noch toll wäre, wäre wenn es da ein wenig Feedback zum User gibt. Muss garnicht so komplex sein einfach nur ne Meldung falls irgendwie Probleme auftauchen (was auch den Neustart überlebt).


    Ich stelle es mit so wie bei epgsearch vor, dort taucht nen Menüpunkt im Hauptmenu auf wenn Timerkonflikte vorhanden sind.


    Also wenn ein Grabber Auffälligkeiten hatte (Exit Code 1 (Errors), 2 (Warnings) oder 3 (Errors und Warnings)) oder das XML nicht den Erwartungen entsprach dann taucht ein Menüpunkt auf der darüber informiert das Grabber X Warnings und/oder Errors hatte oder ob das XML nicht OK war, dann kann man ins syslog schauen was er denn da für Probleme hatte (um sowas wie ne vollgelaufene Partition (wo das Cache Dir draufliegt) sollte man sich dann ja kümmern).



    BTW: Bevor ich es mühevoll ausprobiere... ist generell UTF-8 fürs XML OK? D.h. geht das auch wenn der VDR nicht auf UTF-8 läuft und Zeichen vorkommen die in der aktuellen Locale nicht vorkommen (üblich ist es ja dann diese Zeichen durch "?" zu ersetzen)?
    Oder sollte der Grabber sich um die Umsetzung kümmern?


    cu


    PS: Ja, viele Fragen ;) Aber ich mein Ziel ist nen Grabber der auf allen Systemen fehlerfrei und ohne Fummelei läuft, nicht so wie das TVM2VDR Perl Script wo man auf jeder Linux Version erstmal was rumpatchen muss damit die Sonderzeichen passen ;)
    Deswegen die vielen Fragen nach den genauen Vorgaben.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!