Idee: xmltv2vdr-plugin

Keine_Ahnung · 3. Dezember 2010

Zitat

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

Zitat

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

pinky666 · 3. Dezember 2010

Zitat
Original von Joe_D
Die RFC2838-Notation finde ich gar nicht so übel:
Code
theater.zdf.de
dokukanal.zdf.de
doku.zdf.de
info.zdf.de

Um die Verwirrung komplett zu machen wären doch auch

Code

pro7.prosiebensat1mediaag.de
prosieben.prosiebensat1mediaag.de
sat1.prosiebensat1mediaag.de
kabeleins.prosiebensat1mediaag.de
kabel1.prosiebensat1mediaag.de
neunlive.prosiebensat1mediaag.de
9live.prosiebensat1mediaag.de
sixx.prosiebensat1mediaag.de

RFC konform.

steffen_b · 3. Dezember 2010

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.

Keine_Ahnung · 3. Dezember 2010

Zitat

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

Joe_D · 7. Dezember 2010

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

pipe,plugin,00:00
ard.de,001
*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

Joe_D · 8. Dezember 2010

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

Code

rtl.de
sat1.de
prosieben.de
kabel1.de
rtl2.de
vox.de
das-vierte.de
tele5.de
superrtl.de

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

Code

0=Alles OK
1=allgemeiner Fehler (z.B. out of memory,...)
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 · 8. Dezember 2010

üblicherweise mache ich CLRE um dann den Tag neu zu laden, aber das hängt sicher von der Quelle ab, bei mir 18 Tage im voraus ... würde ich eher nicht drauf verzichten ...

Joe_D · 8. Dezember 2010

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

pipe;plugin;00:00;18
4
*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

M-Reimer · 8. Dezember 2010

Was bewirkt eigentlich der SVDRP-Befehl "PUTE"? Kann man damit mit VDR-Bordmitteln einen EPG-Eintrag überschreiben *und* sperren?

Joe_D · 8. Dezember 2010

@Mreimer

Zitat

Was bewirkt eigentlich der SVDRP-Befehl "PUTE"?

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

Zitat

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

Keine_Ahnung · 8. Dezember 2010

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

Joe_D · 8. Dezember 2010

Keine_Ahnung

Zitat

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:

Code

68       cEvent *pEvent = (cEvent *)pSchedule->GetEvent(SiEitEvent.getEventId(), StartTime);
  69       if (!pEvent) {
  70          if (OnlyRunningStatus)
  71             continue;
  72          // If we don't have that event yet, we create a new one.
  73          // Otherwise we copy the information into the existing event anyway, because the data might have changed.
  74          pEvent = newEvent = new cEvent(SiEitEvent.getEventId());
  75          if (!pEvent)
  76             continue;
  77          }
  78       else {
  79          // We have found an existing event, either through its event ID or its start time.
  80          pEvent->SetSeen();
  81          // If the existing event has a zero table ID it was defined externally and shall
  82          // not be overwritten.
  83          uchar TableID = pEvent->TableID();
  84          if (TableID == 0x00) {
  85             if (pEvent->Version() == getVersionNumber())
  86                continue;
  87             HasExternalData = ExternalData = true;
  88             }

Alles anzeigen

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

Keine_Ahnung · 8. Dezember 2010

Zitat

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.

Zitat

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

steffen_b · 8. Dezember 2010

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

Keine_Ahnung · 8. Dezember 2010

Zitat

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

Zitat

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.

Zitat

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

Zitat

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

steffen_b · 10. Dezember 2010

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.

Joe_D · 10. Dezember 2010

steffen_b

Zitat

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.

Zitat

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.

Zitat

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

steffen_b · 10. Dezember 2010

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

Keine_Ahnung · 10. Dezember 2010

Zitat

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

Joe_D · 24. Dezember 2010

Anbei mal ein "Teaser" für die Weihnachtstage

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

Code

pipe;00:00
1;16
*rtl.de;004
sat1.de;005
*prosieben.de;006
kabel1.de;008
rtl2.de;009
*vox.de;011
das-vierte.de;067
tele5.de;105
superrtl.de;179

Alles anzeigen

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

Idee: xmltv2vdr-plugin

Jetzt mitmachen!

Teilen