VDR Portal

OK, habs gefunden:

damit schmiert das Plugin ab


damit nicht


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

Quoted from "ludi"

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

Quoted from "ludi"

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

Quoted

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.

Quoted

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.

Quoted

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)

Quoted

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?

Quoted

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

Quoted from "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?

Quoted from "Joe_D"

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

Quoted from "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).

Quoted from "ludi"

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

Quoted from "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...

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

Quoted from "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...

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

Quoted from "hepi"

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

Quoted from "hepi"

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:

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

Quoted from "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.

Quoted from "hepi"

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/index.php/Xm…iche_Kanalliste

Quoted from "hepi"

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.

Quoted from "hepi"

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

Quoted

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

Quoted

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.

Quoted

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.

Quoted

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:



funktioniert das ganze soweit problemlos.

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



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?

Quoted from "Wyse"

Das Layout ist eher Grenzwertig

Inwiefern?

Quoted from "Wyse"

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

Nein.

Gruß

Joe_D