xmltv2vdr-plugin importiert keine Daten - wieso?

  • OK, habs gefunden:


    damit schmiert das Plugin ab

    Code
    drwxr-xr-x 2 root    root    4096 12. Mai 12:52 epgsources


    damit nicht

    Code
    drwxr-xr-x 2 vdr    vdr    4096 12. Mai 12:52 epgsources


    Irgendwie logisch, aber warum kann ich bei der ersten Variante die Datei als User vdr mit vi editieren?


    Aber egal, evtl. sollte dasPlugin den Fall abfangen das die Zugriffsrechte nicht stimmen?


    cu

  • Hi,

    Zitat

    xmltv2vdr interessiert nur das dieser Grabber den Sender "tf1.fr" liefern kann, der Rest muss der Grabber machen. xml2vdr soll ja bewusst unabhängig von den div. Datenquellen arbeiten und sich nicht auf bestimmte Datenquellen (oder deren spezielle Eigenheiten) festlegen.

    xmltv2vdr wurde immer noch unabhängig von der Datenquelle bleiben, auch wenn die Datenquelle andere Sender ids benutzt; die Unabhängigkeit würde von der Steuerdatei geleistet, wenn sie die Zuordnung zwischen den Sendernamen der Quelle und den Standardnamen des xmltv2vdr angibt.


    Zitat

    Ich weiss aber worauf Du hinaus möchtest, nämlich den Zwischenschritt "irgendeine ID von einer schon bestehenden xmltv-Quelle auf die xmltv2vdr-KanalIDs" zu sparen. Aber genau den Zwischenschritt sollte ja der xmltv2vdr-Grabber machen.

    Im Augenblick mache ich diesen Zwischenschritt mit sed, was auch schnell geht. Aber aus Neugier: Warum muss der Grabber den Zwischenschritt tun? Welchen Sinn hat die Restriktion auf die Standardnamen des xmltv2vdr, wenn die Steuerdatei die Zuordnung angeben könnte?


    Zitat

    Das xmltv Projekt und das dort verwendete Datenaustauschformat sind ja zwei verschiedene Sachen.

    Es ging mir ja nicht darum, die Senderids des xmltv Projekts automatisch zu erkennen. Ich dachte am Anfang, dass die Steuerdatei für die Zuordnung zuständig wäre. Jetzt weiß ich dass das nicht der Fall ist und dass die xmltv Daten die Standardnamen von xmltv2vdr benutzen müssen.


    Zitat

    merge = mischen, d.h. vorhandene EPG-Enträge erweiteren (bei Ausfall des Grabbers werden trotzdem noch Aufnahmen gemacht, da das Sender-EPG greift)
    append = hinzufügen, d.h. neue EPG-Einträge erstellen (geht aber nur wenn es entweder kein EPG gibt oder der Kanal mit dem noEPG-Plugin/Patch gesperrt wurde, bei Ausfall des Grabbers wird nichts aufgenommen!)

    Jetzt bin ich überrascht: Gehen Timer bei dem vdr nur wenn es auch entsprechende EPG-Einträge gibt? Oder ist das speziell der Suchtimerfunktion zugeschnitten, die automatisch das EPG durchsucht um Timer zu setzen? Ich bin noch nicht lange dabei in Sachen vdr; folglich entgeht mir manchmal der Sinn warum einige Sachen so sind wie sie sind.


    Ich probiere die Beschreibung von merge und append anders auszudrücken. Ist folgendes korrekt?
    merge: Falls der EPG-Eintrag schon existiert, wird er mit den neuen Daten erweitert; gibt es den noch nicht, dann werden die neuen Daten ignoriert.
    append: Gibt es schon einen Eintrag, so werden die neuen Daten ignoriert; gibt es den Eintrag noch nicht, so wird er mit den neuen Daten erstellt.


    Falls meine Beschreibung von merge und append wirklich korrekt ist, vermisse ich sehr folgende dritte Option: Falls der EPG-Eintrag schon existiert, füge die neuen Daten hinzu; existiert der EPG-Eintrag noch nicht, dann erstelle ihn mit den neuen Daten. (Eigentlich hatte ich das unter "merge" angenommen, bis ich die Meldungen im Log sah, dass der Event nicht existierte und er nichts importierte.)


    MfG

  • xmltv2vdr wurde immer noch unabhängig von der Datenquelle bleiben, auch wenn die Datenquelle andere Sender ids benutzt; die Unabhängigkeit würde von der Steuerdatei geleistet, wenn sie die Zuordnung zwischen den Sendernamen der Quelle und den Standardnamen des xmltv2vdr angibt.


    Die Frage ist warum sollte xmltv2vdr dieses Mapping machen? Der Grabber kann doch gleich das XML mit den korrekten Senderbezeichnungen liefern. Der Grabber muss das XML doch eh erstellen (das du dir bereits als XMLTV XML bekommst ist ja nen Sonderfall, der vermutlich am Anfang auch nicht berücksichtigt wurde da xmltv in DE eh nutzlos ist), also kann er es gleich richtig machen.


    Klar, ich verstehe deine Idee, aber am Ende bleibt die Anwendung ein Sonderfall, denn ein üblicher Grabber muss eh mehr tun als deiner tut (z.B. die geladenen Daten aufräumen und evtl. mergen).



    BTW: Genau über diesen Punkt wurde anfangs sehr viel Diskutiert ;) Joe_D hat diese Sache ja anfangs zur Diskusion gestellt. Ist also nicht so als ob das vorher nicht mal besprochen wurde, jetzt ist es halt so wie es jetzt ist. Irgendwann muss man halt mal nen Punkt machen und ne Schnittstelle festlegen die dann auch so bleibt (auch wen sie evtl. nicht Ideal ist).


    die Unabhängigkeit würde von der Steuerdatei geleistet, wenn sie die Zuordnung zwischen den Sendernamen der Quelle und den Standardnamen des xmltv2vdr angibt.


    BTW: Gerade das hier halte ich nicht für Ideal, das Mapping gehört IMHO in eine seperate Datenbank (z.B. eine CSV Datei) des Grabbers (so das sie auch mit einem normalen Update des Grabbers automatisch aktuallisiert wird) und nicht mit der Config vermischt.


    Aber das kann jeder Grabber so halten wie er will. Dafür gibts halt das frei verfügbare Datenfeld dort.


    Ganz allgemein ist die Schnittstelle IMHO schon gut so wie sie ist.


    cu

  • ludi


    Zitat

    Welchen Sinn hat die Restriktion auf die Standardnamen des xmltv2vdr, wenn die Steuerdatei die Zuordnung angeben könnte?

    Der Sinn besteht darin, das xmltv2vdr seine xmltv-Dateien egal von welcher Quelle in einem Standardformat bekommt. Das wurde eben so festgelegt.


    Zitat

    Jetzt bin ich überrascht: Gehen Timer bei dem vdr nur wenn es auch entsprechende EPG-Einträge gibt?

    Naja, Timer auf "Sendungsnamen" gehen aus Prinzip nur mit EPG.


    Zitat

    Ich probiere die Beschreibung von merge und append anders auszudrücken. Ist folgendes korrekt?
    merge: Falls der EPG-Eintrag schon existiert, wird er mit den neuen Daten erweitert; gibt es den noch nicht, dann werden die neuen Daten ignoriert.
    append: Gibt es schon einen Eintrag, so werden die neuen Daten ignoriert; gibt es den Eintrag noch nicht, so wird er mit den neuen Daten erstellt.

    Korrekt (wobei es bei append nur Einträge geben kann, wenn welche von xmltv2vdr erstellt wurden - und zudem muss man Vorkehrungen treffen das das Sender-EPG nicht geladen wird)


    Zitat

    Falls der EPG-Eintrag schon existiert, füge die neuen Daten hinzu; existiert der EPG-Eintrag noch nicht, dann erstelle ihn mit den neuen Daten.

    Dann wünsche ich viel Spass mit doppelten EPG-Einträgen ;) Beim VDR kann immer nur einer EPG erstellen, entweder der Sender oder xmltv2vdr. Da Sender und xmltv2vdr unterschiedliche Event-IDs verwenden würde es bei Deinem gewünschten Fall dazu führen, das zum xmltv2vdr-Event ein Sender-Event erstellt werden würde.


    Keine_Ahnung


    Bei mir schmiert nichts ab (egal ob vdr/root - bei mir kommen dann nur entsprechende Logmeldungen), kannste einen Backtrace machen?


    Zitat

    das Mapping gehört IMHO in eine seperate Datenbank (z.B. eine CSV Datei) des Grabbers (so das sie auch mit einem normalen Update des Grabbers automatisch aktuallisiert wird) und nicht mit der Config vermischt.

    Da war ich eben faul ;) Es wäre eine bessere Lösung, nur benötigt man dann auch noch einen Mechanismus der die Config-Datei erweitert/ändert wenn z.B. ein Sender eingestellt wird oder neu hinzukommt.


    Gruß


    Joe_D

  • Bei mir schmiert nichts ab (egal ob vdr/root - bei mir kommen dann nur entsprechende Logmeldungen), kannste einen Backtrace machen?


    Ich kanns hier zuverlässig reproduzieren, richtige Rechte = aller fein; falsche Rechte = schmiert ab.



    Keine Ahnung obs dir weiterhilft, ist mein erster BT. Bin aber Testwillig, must nur sagen was ich tun soll.


    BTW: Erzeugt mit
    gdb /opt/vdr-1.6.0-2/vdr /home/vdr/core.vdr.5846.1305233917
    und dann "bt" eingegenben.


    Edit: Ich sehe gerade im Quelltext du legst nen neues File an und ersetzt damit das alte. Dann ist ja klar warum das Verzeichnis Schreibrechte benötigt. Evtl. wäre es sinnig das im Readme hinzuzufügen?


    Da war ich eben faul ;)


    Jup, und ich will es perfekt, deswegen läuft deine Lösung jetzt schon und bei mir ist es immer noch in der Planungsphase ;) Faul sein ist meist der richtige Ansatz. Wollts nur mal erwähnen, nicht das stille Mitlerser die gerade nen Grabber schreiben denken das muss so sein.


    cu

  • Hallo,


    Erstens vielen Dank für eure Erläuterungen; ihr habt mir schon sehr weitergeholfen. Leider sind die Import Modi merge und append noch nicht ganz klar für mich; insbesondere das Problem mit den Doppeleinträge:


    Also wenn ich richtig verstanden habe, bekommt jede Sendung in der EPG-Quelle eine Sendung-ID und diese Sendung-ID variert von Quelle zu Quelle; korrekt?


    Weiter hatte ich den merge folgendermaßen definiert, und es wurde als korrekt bestätigt:

    Zitat

    merge: Falls der EPG-Eintrag schon existiert, wird er mit den neuen Daten erweitert; gibt es den noch nicht, dann werden die neuen Daten
    ignoriert.

    Müsste meine Definition nicht folgendermaßen lauten um genauer zu sein:

    Zitat

    merge: Falls die Sendung-ID schon existiert, und in den neuen Daten befindet sich eine gleiche Sendung-ID, so wird erstere mit letztere erweitert; alle Sendungen aus den neuen EPG Daten werden ignoriert, falls ihre Sendung-ID nicht schon im EPG des VDRs existiert.

    Stammt dieses Verhalten vom VDR selbst, oder wurde das so in das xmltv2vdr plugin programmiert?


    Wenn ich jetzt das EPG für einen Sender von zwei verschiedenen Quellen bekomme und der Import für den Sender auf append steht, habe ich
    dann nicht doppelte Einträge da ich davon ausgehen kann, dass beide Quellen verschiedene Sendung-IDs benutzen?


    Schließlich, erhält der VDR sein EPG nur über Plugins oder beinhaltet er auch ein internes Verfahren, das sich das EPG holt? Zum Beispiel benötigt der VDR ein plugin um die EPG Daten die mit den deutschen öffentlichen Sender gesendet werden, zu verwerten?


    MfG


    Ludi

  • Also wenn ich richtig verstanden habe, bekommt jede Sendung in der EPG-Quelle eine Sendung-ID und diese Sendung-ID variert von Quelle zu Quelle; korrekt?


    Jein, das mit der Sendungs ID ist ne Sache des Digitalen TVs. Hier hat jede Sendung eine eindeutige ID (Theroetisch, rein praktisch bekommen die Sender das auch nicht auf die Reihe). Und der VDR arbeitet intern so das diese eindeutigen IDs auch benötigt werden.
    Bei EPGs was wir hier zusätzlich einfügen (so was ist vom VDR eigentlich niemanls vorgesehen gewesen) muss halt für jeden Eintrag eine ID erfunden werden. Weil, wenn die Quellen überhaupt eine eindeutige ID verwenden, dann ist das eine interne (die Daten die du da runterlädst sind ja vom Urheber gar nicht für diesen Fall gedacht) die nicht mit der ID des Sender EPG koordiniert ist.


    Also hat xmltv2vdr keine Möglichkeit festzustellen ob ein EPG Eintrag vom Sender, und einer der per XML reinkommt, sich auf die selbe Sendung beziehen oder nicht. Hier kann nur anhand der Sendezeiten und des Titels geraten werden (wie genau xmltv2vdr das macht weiss ich nicht).


    Schließlich, erhält der VDR sein EPG nur über Plugins oder beinhaltet er auch ein internes Verfahren, das sich das EPG holt? Zum Beispiel benötigt der VDR ein plugin um die EPG Daten die mit den deutschen öffentlichen Sender gesendet werden, zu verwerten?



    Die EPG Infos die mit den Sendern selber kommen empfängt und wertet der VDR selber aus. Zusätzliche EPG Infos reinzuschreiben ist vom VDR eigentlich auch nicht vorgesehen. Daher kommen auch einige Probleme, denn eigentlich ist die EPG Verwaltung des VDR für EPG Infos aus verschiedenen gemischten Quellen nicht geeignet.




    Wir basteln hier alle nur um die Unfähigkeit der Sender (vernünftige EPG Infos mitzusenden) und einigen EPG "schwächen" des VDR drumherrum.


    cu

  • Hi,


    ich bin ja eigentlich bisher ein Greenhorn, was Nicht-EIT-EPGs angeht, verfolge diese Diskussion aber mit Interesse und will mich doch mal einmischen. Wie zumindest Keine Ahnung weiß, bin ich ja erst über die Channelpedia-Mehrwert-Diskussion auf EPG-Grabbing-Plugins wie xmltv2vdr aufmerksam geworden.


    Ich halte das xmltv2vdr-Plugin grundsätzlich für eine Super-Sache und könnte mir auch vorstellen, dass man langfristig den Channelpedia-Service erweitern könnte, um eventuell benötigte Mapping-Dateien zu generieren. Das Ziel wäre, den Arbeitsaufwand aller Nutzer kleinzuhalten, denn wenn sich am Ende sowieso alle Leute ähnliche oder identische Mappingdateien (pro Provider) erstellt haben, kann man die Konfig auch einmal für alle generieren.


    Ich denke, dass es im deutschsprachigen Raum die Situation gibt, dass ein Großteil der Nicht-EIT-EPG-Nutzer an tvm2vdr oder ähnliches gewöhnt sind und sich deshalb nur sehr langsam Richtung xmltv2vdr bewegen. Anders sieht es jedoch in anderen Regionen der Welt aus, wo ein tvm2vdr uninteressant ist, weil die deutschen Sender gar nicht empfangen werden können. Zum Beispiel bietet in UK die RadioTimes einen XML-EPG-Service an.


    Deshalb würde ich es als sehr wichtig erachten, dass die deutschsprachige Wiki-Dokumentation des Plugins ins Englische übersetzt wird und ins englischsprachige VDR-Wiki kommt, wo von dem Plugin noch gar nichts zu lesen ist.


    Gleichzeitig scheint mir die Wiki-Dokumentation aber noch zu wenig als Tutorial nutzbar zu sein, was ich aus den hier diskutierten Fragen ableite. So gibt es zum Beispiel bei mir nach der mehrmaligen Lektüre der Wiki-Doku immer noch offene Fragen. Deshalb würde ich es gut finden, wenn die Wiki-Doku um ein praktisches Beispiel erweitert werden könnte, wo der gesamte Workflow drin ist, den man machen muss, um es zum Laufen zu kriegen.


    Ich weiß, dass das Plugin recht jung ist und dass es dazu im Wiki schon mehr Doku gibt als zu manchem anderen Plugin. Trotzdem denke ich, dass es der Verbreitung des Plugins helfen würde, wenn die Doku noch ergänzt und übersetzt wird.


    Viele Grüße
    hepi

  • Gleichzeitig scheint mir die Wiki-Dokumentation aber noch zu wenig als Tutorial nutzbar zu sein, was ich aus den hier diskutierten Fragen ableite. So gibt es zum Beispiel bei mir nach der mehrmaligen Lektüre der Wiki-Doku immer noch offene Fragen. Deshalb würde ich es gut finden, wenn die Wiki-Doku um ein praktisches Beispiel erweitert werden könnte, wo der gesamte Workflow drin ist, den man machen muss, um es zum Laufen zu kriegen.


    Jetzt wo du es sagst.... ;) Stimmt, für den Neueinsteiger ist es vermutlich doch etwas verwirrend.


    Das was da im wiki steht richtet sich ja eigentlich an die Devs und nicht an die Nutzer. Im Prinzip gehts ja darum das das Plugin Grapper Plugins für die benötigten Quellen benötigt (So wie z.B. auch das text2skin Plugin Skin Plugins).
    Evtl. wäre es wirklich sinniger die wiki Beschreibung so ganz klassisch für die reine Plugin Nutzung zu schreiben und die technischen Infos zum erstellen der Grabber-Plugins auf ne zweite Seite auszulagern? Das würde das Konzept vermutlich auch erstmal besser rüberbringen. Weil so hat man schon irgendwie den Eindruck (so ganz spontan beim ersten Blick auf die Seite) das der reine Nutzer da unheimlich viel Konfigurieren muss (könnte sein das die Wiki seite erstmal abschreckt?).


    Das Problem ist nur das noch kein einziger Grabber veröffentlicht wurde. Aber das würde sich vermutlich wirklich ändern wenns auch ausserhalb von DE etwas bekannter würde (scheinen ja nur wieder wir zu sein die um die EPG Daten son Zauber machen).



    Für den reinen Nutzer ist ja die Idee das er das PLugin installiert (so ganz normal ohne irgendwas spezielles) und dann den Grabber seiner Wahl (Grabber Programmdateien nach /usr/bin und steuerdatei nach /var/lib/epgsources). Und dann läuft das ohne irgendwelches Gefummel einfach so. Es braucht also für die User keine grosartige extra Erklärung. Es fehlen im Moment einfach nur die Grabber.


    Der Grabber für TVMovie existiert ja schon, und läuft out of the Box einfach so (das tvm2vdr Plugin ist somit eigentlich schon überflüssig), das einzige Problem ist die Frage obs man sowas veröffentlichen kann?


    cu

  • 1) Zum Wiki: Es spricht ja nichts gegen mehrere Wiki-Seiten, die sich auf ein Plugin beziehen, solange man alles korrekt verlinkt und erklärt. Auf der jetzigen Wiki-Seite wird nicht erklärt, welche Textabschnitte sich an Devs und welche sich an Nutzer richten. Am Anfang steht aber der Nutzer, weil der Dev auch Nutzer ist... :D


    2) Vorschlag: Kanalbezogene Konfiguration nicht in der setup.conf ablegen


    EPG-Daten haben immer etwas mit der channels.conf zu tun: Je mehr Kanäle in der channels.conf, desto mehr EPG-Daten in der epg.data. Soweit nichts weltbewegendes, aber: Seit ich mich mal mit dem NoEPG-Patch auseinandergesetzt habe, bin ich ich der Ansicht, dass die Konfigurationszeilen des NoEPG-Patches eigentlich sehr schlecht manuell wartbar sind, sprich: Eine ellenlange Zeile mit Kanal-IDs, die man nicht durch menschlich lesbare Kommentare versehen kann. Die NoEPG-Konfig wird tendenziell auch immer umfangreicher, je mehr Kanäle man in der channels.conf hat. Das finde ich eigentlich ungünstig, dass die Konfigurationszeile in der setup.conf drinsteht und nicht in einer eigenen Konfig-Datei, wo man die Kanal-IDs umbrochen verwalten könnte und menschlich lesbar kommentieren könnte (vergleiche Aufbau einer channelmap.conf-Datei). (Bietet eigentlich der NoEPG-Patch ein Verwaltungsmenü per OSD?)


    Genau das gleiche gilt dann meiner Meinung nach für den Umfang der Konfigurationszeilen, die xmltv2vdr in der setup.conf anlegt: Je länger meine channels.conf und je intensiver ich xmltv2vdr nutzen würde, desto umfangreiche sind die dadurch in der setup.conf abgelegten Konfigurationsoptionen - pro Kanal eine Zeile, wenn ich mich nicht irre.


    Bei epgsearch gibt es beispielsweise solche Konfigurationsdateien (zum Beispiel epgsearchchangrps.conf und epgsearchblacklists.conf), wo man kanal-bezogene Daten in externen Dateien verwalten kann (ob die Verwaltung dadurch kinderleicht wird, ist eine andere Frage).


    Fazit: Ich frage mich, ob Datensätze, die sich auf die channels.conf beziehen, nicht besser in eigenen Konfigurationsdateien aufgehoben sind, weil der Umfang der Daten variiert. Eigene Konfigurationsdateien machen die Konfiguration noch nicht von sich aus kinderleicht, aber sie wären eine Voraussetzung dafür.


    Eigene Konfigurationsdateien böten folgende Vorteile, dass


    a) Menschen sie leichter manuell ändern können, weil sie sich besser darin orientieren können (keine Mischung von Konfigurationsbereichen, Kommentare am Zeilenende möglich)
    b) Dass ein Nutzer die Dateien leichter komplett austauschen kann, wenn sie automatisch mit externen Tools generiert worden sind
    c) Dass die setup.conf von der Länge der Zeilen her überschaubar bleibt.


    3) Verstehe ich es richtig, dass die RID, also der letzte Kanalparameter in der channels.conf genutzt wird, um die UniqueID pro Kanal zu hinterlegen?


    Gruß
    hepi

  • 1) Zum Wiki: Es spricht ja nichts gegen mehrere Wiki-Seiten, die sich auf ein Plugin beziehen, solange man alles korrekt verlinkt und erklärt. Auf der jetzigen Wiki-Seite wird nicht erklärt, welche Textabschnitte sich an Devs und welche sich an Nutzer richten. Am Anfang steht aber der Nutzer, weil der Dev auch Nutzer ist... :D


    Stimmt, wenn Joe_D da für die wiki Seite keine konkreten Pläne hat, dann würde ich mich da mal dran versuchen.


    2) Vorschlag: Kanalbezogene Konfiguration nicht in der setup.conf ablegen


    EPG-Daten haben immer etwas mit der channels.conf zu tun: Je mehr Kanäle in der channels.conf, desto mehr EPG-Daten in der epg.data. Soweit nichts weltbewegendes, aber: Seit ich mich mal mit dem NoEPG-Patch auseinandergesetzt habe, bin ich ich der Ansicht, dass die Konfigurationszeilen des NoEPG-Patches eigentlich sehr schlecht manuell wartbar sind, sprich: Eine ellenlange Zeile mit Kanal-IDs, die man nicht durch menschlich lesbare Kommentare versehen kann. Die NoEPG-Konfig wird tendenziell auch immer umfangreicher, je mehr Kanäle man in der channels.conf hat. Das finde ich eigentlich ungünstig, dass die Konfigurationszeile in der setup.conf drinsteht und nicht in einer eigenen Konfig-Datei, wo man die Kanal-IDs umbrochen verwalten könnte und menschlich lesbar kommentieren könnte (vergleiche Aufbau einer channelmap.conf-Datei). (Bietet eigentlich der NoEPG-Patch ein Verwaltungsmenü per OSD?)


    Es gibt das noEPG Plugin mit dem man die Kanäle bequem per OSD sperren kann.


    Zum "eindeutiger Kanalname" <-> "Kanallisteneintrag" Mapping... Joe_D hat es ja ausdrücklich vorgesehen sowas bequem im xmltv2vdr Menu zu konfigurieren (die Grundidee war ja das der User ebend nicht in Config Files rumeditieren muss).
    Wobei ich es ja super fände wenns in ner extra Configdatei wäre, die man auch (zusätzlich zur OSD Einstellmöglichkeit) komplett irgendwo downloaden könnte (z.B. von Channelpedia) oder die eine Distribution gleich fertig mitliefern könnte (für die standart Empfangswege).



    3) Verstehe ich es richtig, dass die RID, also der letzte Kanalparameter in der channels.conf genutzt wird, um die UniqueID pro Kanal zu hinterlegen?


    So wie ich das verstehe steht der zur freien Verfügung, AFAIK kann man den nutzen um mehere identische Kanallisteneinträge zu haben (die der VDR ansonsten entfernen würde).


    cu

  • Denkfehler bei mir: Das Mapping von Kanal-Eintrag in der channels.conf zu Kanal-ID wird ja derzeit dann in der setup.conf über eine Zeile wie diese vorgenommen:

    Code
    xmltv2vdr.channel.france2.fr = 16;284165119;S19.2E-1-1090-9022;S19.2E-1-1074-8374


    Somit muss die channels.conf selbst nicht modifziert werden.


    Die Grundfrage ist für mich hinsichtlich einer Channelpedia-Erweiterung : Sind die Ansprüche der Anwender an xmltv2vdr individuell sehr unterschiedlich? Wenn jeder Anwender sich sein xmltv2vdr über das OSD anders konfiguriert und damit die Zeilen in der setup.conf, die mit "xmltv2vdr.channel." anfangen, bei jedem Anwender anders aussehen, dann kann die Channelpedia hier keine Hilfestellung leisten, weil automatisch generierte Konfigurationszeilen an den Anforderungen der Anwender vorbeigehen.


    Wenn aber beispielsweise bei deutschsprachigen Nutzern die Konfiguration immer gleich aussieht, weil die immer gleiche Kanalparade für sie interessant ist, dann lohnt sich die automatische Generierung vielleicht schon, und bei Channelpedia wäre es möglich, nicht nur für S19.2E zu generieren, sondern für alle gepflegten Anbieter (also auch Kabel und DVB-T).


    Gruß
    hepi


  • Die Grundfrage ist für mich hinsichtlich einer Channelpedia-Erweiterung : Sind die Ansprüche der Anwender an xmltv2vdr individuell sehr unterschiedlich? Wenn jeder Anwender sich sein xmltv2vdr über das OSD anders konfiguriert und damit die Zeilen in der setup.conf, die mit "xmltv2vdr.channel." anfangen, bei jedem Anwender anders aussehen,


    Sie sind z.B bei jedem Astra 19,2 Nutzer identisch.
    Weil hier wird ja im Prinzip nur festgelegt welcher Sender (Sender meint Programmlieferant, RTL und RTL HD sind ja mit Sicht aufs EPG identische Sender) auf welchen Kanallisteneintrag mappt (Wobei der Sender hier durch eine festgelete Normbezeichnung identifiziert wird (Liste im Wiki)). Und das ist ja bei allen Astra 19,2 Nutzern identisch, genauso wie bei allen Kabeldeutschland nutzern.



    und bei Channelpedia wäre es möglich, nicht nur für S19.2E zu generieren, sondern für alle gepflegten Anbieter (also auch Kabel und DVB-T).


    Jup, das würde den Konfigurationaufwand vereinfachen. Dazu müsste Joe_D nur auch gewillt sein diese Konfiguration in ne eigene Datei auszulagern (keine Ahnung wie er zum Thema steht?)


    Wobei die vereinfachung der Konfiguration im Moment eh niemanden helfen wird, denn es gibt ja noch keine Grabber ;) Das es keine Grabber gibt ist ja wohl der Grund warum das Plugin im Moment eh kaum genutzt wird (ich vermute jedenfall das es nur von wenigen genutzt wird).


    cu

  • OK. Das heißt also, dass ich für beliebig viele Kanäle in der setup.conf eine Zuordnung zwischen Sender-Parameter-ID (source-sid-nid-tid[-rid]) und festgelegter UniqueID ( z. B. "zdf.de") vornehmen kann, selbst wenn ich nur für drei dieser Sender das EPG via xml-grabber beziehe.
    Sprich: Wenn auf Astra1 (S19.2E) insgesamt 1300 Kanäle empfangbar sind (nur mal geraten), kann ich theoretisch in der setup.conf auch 1300 Zeilen haben mit Zuordnungen, auch wenn ich am Ende nur für 35 deutschsprachige Sender das EPG vial xml-Grabber beziehe.


    In den Sourcen des Plugins finde ich keine Repräsentanz der verbindlichen Kanalliste [1]. Kennt das Plugin selbst die Liste der verbindlichen Kanäle selbst oder muss es die Liste nicht kennen? Man wird dann aber nicht gezwungen, diese Liste auch einzuhalten?


    Gruß
    hepi


    [1] http://www.vdr-wiki.de/wiki/in…n#Verbindliche_Kanalliste

  • OK. Das heißt also, dass ich für beliebig viele Kanäle in der setup.conf eine Zuordnung zwischen Sender-Parameter-ID (source-sid-nid-tid[-rid]) und festgelegter UniqueID ( z. B. "zdf.de") vornehmen kann, selbst wenn ich nur für drei dieser Sender das EPG via xml-grabber beziehe.
    Sprich: Wenn auf Astra1 (S19.2E) insgesamt 1300 Kanäle empfangbar sind (nur mal geraten), kann ich theoretisch in der setup.conf auch 1300 Zeilen haben mit Zuordnungen, auch wenn ich am Ende nur für 35 deutschsprachige Sender das EPG vial xml-Grabber beziehe.


    Theoretisch ja, rein praktisch müsste man mal probieren wie das Plugin darauf reagiert.


    In den Sourcen des Plugins finde ich keine Repräsentanz der verbindlichen Kanalliste [1]. Kennt das Plugin selbst die Liste der verbindlichen Kanäle selbst oder muss es die Liste nicht kennen? Man wird dann aber nicht gezwungen, diese Liste auch einzuhalten?


    Das Plugin kennt die Liste nicht. Aber die Grabber sind per definition dazu gezwungen sich daran zu halten, weil wenn zwei Grabber für den selben Kanal verschiedene Namen nutzen gibts Fehlfunktionen.


    Die Sache mit der verbindlichen Kanalliste war ja auch erstmal nur der Versuch der dabei rauskam die Sache überhapt mal generell in den Griff zu bekommen (Das ganze Grundkonzept ist ja die Sache mal generell längerfristig in den Griff zu bekommen und nicht nur ne schnelle spezielle Lösung zu finden). Weil bissher nahm sich noch niemand (in der VDR Welt) dieses Problems an. Aber so richtig fertig ist das noch nicht (Die Liste ist ja noch nicht mal für DE komplett).


    cu

  • ludi


    Zitat

    Wenn ich jetzt das EPG für einen Sender von zwei verschiedenen Quellen bekomme und der Import für den Sender auf append steht, habe ich
    dann nicht doppelte Einträge da ich davon ausgehen kann, dass beide Quellen verschiedene Sendung-IDs benutzen?

    Ja das müsste so sein. Habe ich aber noch nie ausprobiert.


    hepi


    Zitat

    Auf der jetzigen Wiki-Seite wird nicht erklärt, welche Textabschnitte sich an Devs und welche sich an Nutzer richten

    Die Wiki-Seite richtet sich ausschließlich an Devs, der Nutzer einer Distribution geht ins Setup-Menü, wählt Kanäle und Informationsgehalt aus und macht eine Zuordnung zu seinen eigenen Kanälen. Fertig. Aber das ist noch Zukunftsmusik.


    Zitat

    Ich frage mich, ob Datensätze, die sich auf die channels.conf beziehen, nicht besser in eigenen Konfigurationsdateien aufgehoben sind

    Nein, die channels.conf sieht bei jedem anders aus (DVB-S,DVB-C,DVB-T und Mischungen dazu) - generierte Einträge machen da IMHO gar keinen Sinn. Die xmltv2vdr-Einträge in der setup.conf beziehen sich ausschliesslich auf das Plugin (wofür dieser Mechanismus ja gedacht ist), nicht auf die Grabber (!) - das ist schön getrennt. Einmal eingestellt muss man da nur ändern falls ein Kanal seinen Sendeplatz ändert (und das kommt bei "richtigen" Sendern alle Schaltjahre mal vor)


    Die Konfigurationsdateien der Grabber hingegen sind ja "extern", die könnte man sogar automatisch generieren.


    Zitat

    Verstehe ich es richtig, dass die RID, also der letzte Kanalparameter in der channels.conf genutzt wird, um die UniqueID pro Kanal zu hinterlegen?

    Wie bitte? ;)


    Gruß


    Joe_D

  • @Keine Ahnung: Klar, fertig muss es ja nicht sein. Die Channelpedia ist auch alles andere als fertig.


    Ich denke nur, um Standards zu etablieren, hat eine Liste auf einer Wiki-Seite keine große Chance, weil niemand gezwungen wird, die Liste zu erweitern bzw. zu benutzen. Aus Vernunft-Gründen sollte man so eine Liste natürlich verwenden, aber es wäre besser, man würde gleich dazu gezwungen werden. Hier kann die Channelpedia ja helfen: Wenn die Channelpedia die Liste intus hat und verwendet, werden alle automatisch generierten Mappings zwischen Kanal-Parameter-ID und UniqueID konsequent die Einträge aus der Liste verwenden. Wenn Nutzer sich aus Bequemlichkeit entscheiden, diese generierten Mappings zu verwenden, werden sie damit angehalten, auch in ihren Steuerdateien genau diese IDs zu verwenden.


    Und aktuell halten muss man die Liste dann nur an sehr wenigen Stellen und nicht auf allen User-VDRs.


    Gruß
    hepi

  • Joe_D: Ich glaube, ich warte am besten nochmal sechs Monate und schaue dann mal wieder rein beim xmltv2vdr-Plugin. Vielleicht haben sich bis dahin ein paar Sachen für mich geklärt und es wird von mehr Leuten genutzt. Ich will mich mit der Channelpedia nicht aufdrängen.


    Gruß
    hepi

  • Ich hänge mich hier mal dran.


    Ich habe einen Grabber der valide xmltv Daten erstellet. Wenn ich nun manuell eine .xmltv erstelle und diese in dem Verzeichnis /var/lib/epgsources ablege und anschliessend die Steuerdatei(tv_grab_we Name verändert!) mit folgendem Inhalt aufrufe:


    Code
    file
    5;7
    *ard.de
    *zdf.de
    *prosieben.de
    *rtl.de
    *sci-fi.de
    *tnt-serie.de


    funktioniert das ganze soweit problemlos.


    Will ich das nun allerdings via pipe machen bekomme ich nur folgende meldung:


    Code
    Jul  8 12:57:06 yavdrclient vdr: [17275] xmltv2vdr: executing epgsource 'tv_grab_we'
    Jul  8 12:57:07 yavdrclient vdr: [17275] xmltv2vdr: epgsource 'tv_grab_we' returned with 1
    Jul  8 12:57:07 yavdrclient vdr: [17275] xmltv2vdr: waiting 60 seconds (1)
    Jul  8 12:58:07 yavdrclient vdr: [17275] xmltv2vdr importer thread ended (pid=17118, tid=17275)


    Führe ich den grabber direkt via Kommandozeile aus geht es auch...


    LÖSUNG:


    ... wenn ich den richten Nutzer nehme.


    Tja vor lauter Bäumen den Wald nicht geshen. Habe bestimmt 10 Stunden an dem Grabber rumgebastelt und irgendwie vor lauter compilieren vergessen dass der gute ja eine config Datei schreibt. Diese ist natürlich für den Nutzer vdr noch nicht vorhanden und deswegen beendet der Grabber sich entsprechend mit dem exitcode 1. Einfach einmal als VDR tv_grab_we --configure ausgeführt und schon funktioniert das ganze.


    Das Layout ist eher Grenzwertig. Gibt es eine Möglichkeit noch ein paar Zeilenübrüche einfügen zu lassen bzw. das komplette Layout des EPGs selbst zu gestalten?

    WZ: yaVDR (0.5): Gigabyte GA-MA78GM-S2H / AMD 240e / LianLi PC-C50B / atric & Harmony 650 / 2GB G.Skill 800 / 2x TT S2-1600 1x TT S2-3600 / 60GB OCZ Vertex2 / Gainward G210 passiv
    AZ: yaVDR (0.5): PoV 330-1 (Atom/ION) / MS-Tech MC-1200/ 2GB Kingston VR 800 / TT S2-1600 / OCZ SSD Onyx 32GB / atric & Harmony 600
    EZ: Raspberry Pi - OpenElec
    HL: GA-MA78GM-S2H / AMD 5050e (@1.1V) / 2x DVBSky S952 Dual / 64 GB SanDisk SDSSDP-064G-G25 / 4 GB RAM / BQT E9
    NAS: Synology DS-1511+ (DSM 4.2) / 5x2TB Samsung F4 / Raid 5 / Smargo / Oscam / APC Back-Ups cs 350

Jetzt mitmachen!

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