Externer EPG - Vorschlag für eine Plugin-Schnittstelle

    Da das Thema "Externer EPG" immer wieder hochkommt und bis hin zu "die EPG-Behandlung soll völlig vom VDR getrennt werden" eskaliert (was nicht stattfinden wird, denn der EPG ist eine zentrale VDR-Funktion), mache ich hier mal einen Vorschlag, wie ich mir eine Plugin-Schnittstelle hierfür vorstellen könnte.




    - Die bisherige Sonderbehandlung für Table-ID 0x00 bleibt aus Gründen der Kompatibilität wie gehabt.


    - Die in Version 1.7.25 eingeführte Eigenschaft, daß die komplette Liste ignoriert wird, wenn der erste Event Table-ID 0x00 hat, wird wieder zurückgenommen.


    - Ein Objekt der neuen Klasse cEpgHandler kann von einem Plugin implementiert werden, um externen EPG einzuspeisen.


    - In eit.c passiert folgendes:


    - Unmittelbar zu Beginn der for-Schleife über die SiEitEvents wird die Funktion


    virtual bool cEpgHandler::HandleEitEvent(const SI::EIT::Event *EitEvent);


    aufgerufen. Diese kann den Event entweder selber behandeln und 'true' zurückliefern, woraufhin VDR selber den Event nicht weiter behandelt. Das Plugin muß sich dann aber auch wirklich um alles selber kümmern. Liefert die Funktion 'false' zurück, so wird der normale VDR-Code für diesen Event ausgeführt.


    - Title, ShortText und Description werden über die Funktionen


    virtual bool cEpgHandler::SetTitle(cEvent *Event, const char *Title);
    virtual bool cEpgHandler::SetShortText(cEvent *Event, const char *ShortText);
    virtual bool cEpgHandler::SetDescription(cEvent *Event, const char *Description);


    gesetzt. Die Default-Implementierung ruft wie bisher die entsprechende Set...()-Function des Events auf. Ein Plugin kann diese Funktionen überschreiben und nach eigenem Gutdünken verfahren.


    - Am Ende der for-Schleife wird die Funktion


    virtual void cEpgHandler::HandleEvent(cEvent *Event);


    aufgerufen. Hier kann das Plugin den fertig bearbeiteten Event nochmal "sehen" und letzte Veränderungen durchführen.




    Würde das für diejenigen, die "externen EPG" verwenden wollen, brauchbar sein?


    Klaus

    Zitat von kls


    - Die bisherige Sonderbehandlung für Table-ID 0x00 bleibt aus Gründen der Kompatibilität wie gehabt.


    - Die in Version 1.7.25 eingeführte Eigenschaft, daß die komplette Liste ignoriert wird, wenn der erste Event Table-ID 0x00 hat, wird wieder zurückgenommen.


    Ersatzloses zurücknehmen würde ich schade finden. Wenn man einfach für einen oder zwei Sender das EPG komplett extern beziehen will, dann wäre eine eingebaute "EPG-Sperre" schon praktisch.

    Zitat von Mreimer

    Ersatzloses zurücknehmen würde ich schade finden. Wenn man einfach für einen oder zwei Sender das EPG komplett extern beziehen will, dann wäre eine eingebaute "EPG-Sperre" schon praktisch.


    Dafür gibt es dann doch die Möglichkeit ein noEPG Plugin zu erstellen was ohne VDR Patch auskommt. Das würde das Thema dann endgültig und elegant lösen.


    Und ein noEPG Plugin bei dem der Nutzer seine whitelist/blacklist Kanäle bequem per GUI einstellt oder was von den EPG Plugins per genormter Service Schnittstelle automatisch konfiguriert (d.h. dir fällt dann eh kein Unterschied auf) wird ist auf alle Fälle besser als per SVDRP Dummy Einträge reinzupumpen um das EPG zu sperren.


    cu

    Moin!


    Das hört sich gar nicht mal schlecht an.


    Zitat von kls

    virtual bool cEpgHandler::HandleEitEvent(const SI::EIT::Event *EitEvent);


    Wäre es möglich, auch noch den Kanal mit zu übergeben? Oder kann der EpgHandler das irgendwie anders herausfinden?
    Aber cEIT hat den Kanal sowieso schon geholt, wäre also doppelte Arbeit, wenn der EpgHandler das auch noch mal machen müsste.
    Sollte evtl. noch der cSchedule-Pointer übergeben werden? Was braucht der EpgHandler eigentlich alles vom vdr, damit er arbeiten kann?


    Ich wiederhole noch mal in meinen Worten, damit ich weiß, ob ich das richtig verstanden habe:

    • Der vdr holt die EIT-Daten aus dem DVB-Stream und fragt den EpgHandler, ob er damit was anfangen kann. Der kann dann selbst ein cEvent-Objekt erstellen/modifizieren und dem vdr die Arbeit abnehmen (Rückgabewert "true").
    • Wenn nicht, verarbeitet der vdr die Daten wie bisher und erstellt/modifiziert das entsprechende cEvent-Objekt.
    • Wenn der vdr die Daten selbst verarbeitet, wird dem EpgHandler beim Modifizieren des cEvent-Objekts die Möglichkeit geboten, nur den Title, ShortText und Description zu überschreiben (Rückgabewert "true"). Wenn "false", setzt der vdr die Texte aus den EIT-Daten.
    • Zusätzlich kann der EpgHandler dann noch mal das fertige cEvent sehen und ggf. noch mal ändern (falls er die Set-Funktionen nicht überschrieben hat bzw. irgendwas anderes daran ändern will)


    Ein "noEPG" ließe sich damit realisieren, indem der EpgHandler einfach "true" für die entsprechenden Kanäle an den vdr zurückgibt und gar kein cEvent anlegt.


    Da es unterschiedliche EPG-Quellen gibt und evtl. manche für bestimmte Kanäle besser sind als andere, sollte es möglich sein, mehrere EpgHandler zu registrieren.
    Sobald einer "true" zurückgibt, werden die übrigen einfach nicht mehr gefragt. Die Reihenfolge ergibt sich auch der Ladereihenfolge der Plugins.


    Dem EpgHandler sollte ermöglicht werden, eine eigene ID an das cEvent zu hängen, damit er es leichter wiedererkennen kann.


    Ich hab ein gutes Gefühl bei dieser Sache. :]


    Lars.

    Zitat von mini73


    Wäre es möglich, auch noch den Kanal mit zu übergeben? Oder kann der EpgHandler das irgendwie anders herausfinden?
    Aber cEIT hat den Kanal sowieso schon geholt, wäre also doppelte Arbeit, wenn der EpgHandler das auch noch mal machen müsste.
    Sollte evtl. noch der cSchedule-Pointer übergeben werden? Was braucht der EpgHandler eigentlich alles vom vdr, damit er arbeiten kann?


    Ich kann noch den cSchedule-Pointer an die HandleEitEvent-Funktion mit übergeben.
    cSchedule hat die Channel-ID, damit müsste dann alles bekannt sein, was benötigt wird.


    Zitat


    Ich wiederhole noch mal in meinen Worten, damit ich weiß, ob ich das richtig verstanden habe:

    • Der vdr holt die EIT-Daten aus dem DVB-Stream und fragt den EpgHandler, ob er damit was anfangen kann. Der kann dann selbst ein cEvent-Objekt erstellen/modifizieren und dem vdr die Arbeit abnehmen (Rückgabewert "true").
    • Wenn nicht, verarbeitet der vdr die Daten wie bisher und erstellt/modifiziert das entsprechende cEvent-Objekt.
    • Wenn der vdr die Daten selbst verarbeitet, wird dem EpgHandler beim Modifizieren des cEvent-Objekts die Möglichkeit geboten, nur den Title, ShortText und Description zu überschreiben (Rückgabewert "true"). Wenn "false", setzt der vdr die Texte aus den EIT-Daten.
    • Zusätzlich kann der EpgHandler dann noch mal das fertige cEvent sehen und ggf. noch mal ändern (falls er die Set-Funktionen nicht überschrieben hat bzw. irgendwas anderes daran ändern will)


    Ein "noEPG" ließe sich damit realisieren, indem der EpgHandler einfach "true" für die entsprechenden Kanäle an den vdr zurückgibt und gar kein cEvent anlegt.


    Stimmt alles.


    Zitat


    Da es unterschiedliche EPG-Quellen gibt und evtl. manche für bestimmte Kanäle besser sind als andere, sollte es möglich sein, mehrere EpgHandler zu registrieren.
    Sobald einer "true" zurückgibt, werden die übrigen einfach nicht mehr gefragt. Die Reihenfolge ergibt sich auch der Ladereihenfolge der Plugins.


    OK.


    Zitat


    Dem EpgHandler sollte ermöglicht werden, eine eigene ID an das cEvent zu hängen, damit er es leichter wiedererkennen kann.


    Ungern, denn dann bräuchte wahrscheinlich wieder jeder EPG-Handler seine eigene ID. Es gibt ja bereits die Channel-ID und die Event-ID, das ist ja eigentlich eindeutig.


    Hier mal cEpgHandler, soweit bis jetzt vereinbart:


    Code
    class cEpgHandler : public cListObject {
public:
  cEpgHandler(void) {}
  virtual ~cEpgHandler() {}
  virtual bool HandleEitEvent(cSchedule *Schedule, const SI::EIT::Event *EitEvent) { return false; }
  virtual bool SetTitle(cEvent *Event, const char *Title) { return false; }
  virtual bool SetShortText(cEvent *Event, const char *ShortText) { return false; }
  virtual bool SetDescription(cEvent *Event, const char *Description) { return false; }
  virtual bool HandleEvent(cEvent *Event) { return false; }
  };


    Klaus


    Edit: s/cListBase/cLIstObject/

    Zitat von mini73

    Ich hab ein gutes Gefühl bei dieser Sache.


    Ich auch, danke Klaus!


    Regards
    Frank

    HowTo: APT pinning

    Gefällt mir auch sehr!


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Moin!


    Zitat von kls

    Ungern, denn dann bräuchte wahrscheinlich wieder jeder EPG-Handler seine eigene ID. Es gibt ja bereits die Channel-ID und die Event-ID, das ist ja eigentlich eindeutig.


    Ach ja, klar, das kann sich der EpgHandler dann ja auch in seiner Datenbank merken. Das ist besser.


    Zitat von kls

    Hier mal cEpgHandler, soweit bis jetzt vereinbart:


    Sieht gut aus. Details ergeben sich dann wie immer in der Umsetzung... :)
    Ich bin damit erst mal glücklich, mal sehen, was den anderen Spezies noch so einfällt


    Wow, darauf freue ich mich richtig. :]


    Lars.

    Zitat von kls

    - Folgende speziellen Table-IDs soll es geben:
    * 0x00: Event wird von VDR nicht verändert (wie bisher)
    * 0x01: wie 0x00, aber wenn dies der erste Event in der Liste ist, wird die ganze Liste unverändert gelassen (**)
    * 0x02: es werden nur ParentalRating, Title, ShortText und Description nicht von VDR verändert


    Ich hoffe das bleibt nach wie vor bestehen? Laut Überschrift betrifft das nur die plugin schnittstelle und nicht svdrp. Richtig!

    Server: CPU J1900 | 1x CineS2 | Debian Bullseye headless| VDR 2.6.3
    Client: 2x Himbeere mit vdr

    Zitat von hondansx

    Ich hoffe das bleibt nach wie vor bestehen? Laut Überschrift betrifft das nur die plugin schnittstelle und nicht svdrp. Richtig!


    Nein, da gibt es ja nichts zu erhalten, diese Änderung war ja bisher nicht da, sie sollte erst kommen. Stattdessen kommt ein viel bessere grundlegende Änderung, kein Kompromiss. Der Status Quo mit der Table-ID 0x00 der bis 1.7.24 galt, bleibt erhalten, parallel bekommt der VDR die Möglichkeit per EPG Plugin entsprechend versorgt zu werden.


    Die "Table-ID 0x00 = noEPG" Änderung aus 1.7.25 wird ersatzlos gestrichen und die von Dir genannte Diskussionsgrundlage für 1.7.25 ff. gab es nie als fertige Umsetzung in einer VDR Version.


    Regards
    fnu

    HowTo: APT pinning

    Hallo,


    ich finde die Idee hervorragend, hoffe aber dass auch die Möglichkeit mit 0x02 bleiben wird, wobei ich mir hier auch einen Abgleich von Events die knapp neben der Startzeit liegen wünschen würde.


    Ich nutze für den externen EPG ein eigenes Skript, da wäre 0x02 auf jeden Fall von Vorteil, mit der Plugin-Programmierung habe ich mich noch nicht auseinandergesetzt, wäre also sehr schade, wenn nicht auch die anderen "neuen" Möglichkeiten bleiben würden.



    CafeDelMar


    EDIT: Schadet ja auch keinem. :]

    Zitat von CafeDelMar

    ich finde die Idee hervorragend, hoffe aber dass auch die Möglichkeit mit 0x02 bleiben wird, wobei ich mir hier auch einen Abgleich von Events die knapp neben der Startzeit liegen wünschen würde.


    Da fängt es doch schon an ;) Und dann könnte man noch, und noch, und noch, und dann auf alle Fälle noch...
    Wenn ich da nix übersehe ließe sich dann 0x02 wunderbar per Plugin realisieren. Und da kann man sich dann ja wild austoben.


    Also ich finde die neue Plugin Schnittstelle super, für den der mit dem IST-Zustand zufrieden ist bleibt alles beim alten und wer sich austoben will nutzt die Pluginschnittstelle.
    Und auf SVDRP braucht man IMHO nicht besonders Rücksicht zu nehmen, das war eh nie sonderlich gut für die wilden EPG Sachen geeignet. Das es da mit dem TableID=0 beim alten bleibt (für die kleinen EPG Modifikationen) deckt IMHO alles notwendige ab.


    cu

    Zitat von Keine_Ahnung

    Wenn ich da nix übersehe ließe sich dann 0x02 wunderbar per Plugin realisieren.


    Ein vmtl. ziemlich kompaktes, das z.B. dann auch elegant die "neue" noEPG Möglichkeit mit "nachrüsten" könnte ...


    Regards
    fnu

    HowTo: APT pinning

    Zitat von Keine_Ahnung

    Wenn ich da nix übersehe ließe sich dann 0x02 wunderbar per Plugin realisieren. Und da kann man sich dann ja wild austoben.


    Na klar würde das über die neue Schnittstelle gehen. Aber ich habe ja geschrieben, dass ICH mich mit der Plugin-Programmierung noch nicht auseinandergesetzt habe und zumindest erstmal weiterhin auf eine Skript-Lösung setzte und es daher sehr begrüßen würde, wenn diese neu geplante Möglichkeit mit 0x02 nicht verworfen wird. Das mit dem etwas größzügerigen Matching ist ja nur ein Wunsch, wenn es keinen interessiert, werde ich damit auch leben können. :D


    Und jetzt bitte keine Aussage in der Art, da werden schon viele Plugins oder das eine neue Super-EPG-Plugin kommen, hat beim achso beliebten TrueColor-OSD auch nicht geklappt. :mua

    Da ich darauf Antworten möchte, aber nicht möchte das es hier ausartet habe ich mal hier nen Talk Thread aufgemacht: Talk: Die neue VDR EPG-Pluginschnitstelle...
    Da können wir uns ja austoben.


    cu

    Hi!


    Der Vorschlag von kls gefällt mir und die Erweiterung von mini sind sehr gut.


    Aber verstehe ich das richtig, dass das Lesen der vorhandenen EPG-Daten weiterhin über die epg.data läuft und diese neue Schnittstelle "nur" zum Laden von neuen Daten (von einem exteren Anbieter, etc) da ist?


    Wenn dem so sein sollte, dann hätte ich noch Vorschläge:
    1) Packt das Bereitstellen der vorhanden Daten auch in die Schnittstelle (oder eine zweite)
    2) und macht aus der Default-Implementierung auch eine Implementierung dieser Schnittstelle(n)
    2.1.) zur Laden der Daten aus epg.data
    2.2.) Bereitstellen neuer Daten aus dem DVB-Stream


    Damit würde dann die Sonderbehandlung entfallen und der Code würde vlt einfacher werden.


    Wenn ich das nicht richtig verstanden hatte, dann vergesst den Scheiß von mir da oben ... :D


    Grüße,


    Volker

    VDR1: POV ION 330 mit Media-Pointer MP-S2 auf yaVDR 0.3.1 - enermay 370 Watt - 80GB SSD + 500GB HD - CoolerMaster ATX-620 - VGA2Scart + HDMI
    VDR2: Zotak ZBOX ID40 auf yaVDR unstable - Sundtek DVB-S2 + remote Sundtek - 60GB SSD - HDMI
    VDR3    : Zotak ZBOX ID40 auf yaVDR unstable - remote Sundtek - 500GB HD - DVI
    Atom 2700 mit 13W, Ubuntu PP, 60GB SDD + 240GB SSD, 2x Sundtek DVB-S2

    Zitat von C-3PO

    Klasse, und wieder verläuft sich ein wichtiges Thema in 100 verschiedene, völlig unnötige Extrathreads...


    Das stimmt doch gar nicht, CafeDelMar hatte den Thread nur für sein Zwecke gehijackt, jetzt hat man hier wieder die Chance sich um das eigentliche Thema zu kümmern.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

    Zitat von gda


    Das stimmt doch gar nicht, CafeDelMar hatte den Thread nur für sein Zwecke gehijackt, jetzt hat man hier wieder die Chance sich um das eigentliche Thema zu kümmern.


    War nicht meine Absicht! Ich wollte lediglich zustimmen, dass diese Plugin-Schnittstelle eine sehr gute Idee ist! :]
    Dass sie das andere zuvor geplante neue Handling nicht ersetzen soll, war mehr eine zusätzliche Bemerkung und Meinung und ich denke hier auch am richtigen Ort. Gegen eine Diskussion habe ich nichts, wollte damit aber auch keine lostreten!


    Und nicht, dass ich das Thema noch wirklich hijacke, bitte wenn nötig ggf. per PM oder anderem Thread antworten. Wegen anderen Verpflichtungen kann ich aber ggf. erst nächste Woche wieder darauf eingehen.

    Zitat von V_R


    Aber verstehe ich das richtig, dass das Lesen der vorhandenen EPG-Daten weiterhin über die epg.data läuft und diese neue Schnittstelle "nur" zum Laden von neuen Daten (von einem exteren Anbieter, etc) da ist?


    Wenn dem so sein sollte, dann hätte ich noch Vorschläge:
    1) Packt das Bereitstellen der vorhanden Daten auch in die Schnittstelle (oder eine zweite)


    Wer epg.data nicht haben will braucht bloß die Option -E- beim Programmstart anzugeben.


    Klaus

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden