Beiträge von kls


    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/

    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


    Es gibt noch eine andere Änderung, die Klaus ohne Probleme übernehmen kann. Programme, die nur Digitalton aussenden, führen zu einer falschen ChangedPids-Meldung. Die Änderung wäre:


    Super! Schön, daß die Ursache hierfür endlich gefunden worden ist.
    Ich werde es aber wohl so machen:



    Damit gar nicht erst hochgezählt wird, wenn eine 0 kommt.
    Da das Gleiche auch bei dpids möglich wäre, hab ich es dort auch gleich so geändert.


    Klaus


    P.S.: Wie immer gilt: wer in der HISTORY/CONTRIBUTORS genannt werden will, bitte Email mit vollem Namen an mich schicken.


    kls: Hier wurde das Problem gemeldet, dass auf verschlüsselten Sendern die PIDs aktualisiert werden, obwohl diese gleich geblieben sind. Als Problemlösung wurde folgendes vorgeschlagen: softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin


    Inwiefern kann das zum Problem werden? Kann das ein Fehler sein, der durch den Einsatz des "bösen Plugins" entsteht und sonst gar nicht auftritt?


    Daß das vom "bösen Plugin" kommt, glaube ich eher nicht.


    Das CHANNELMOD_RETUNE zu ändern könnte dazu führen, daß bei einer Aufnahme der Kanal nach einer tatsächlichen Änderung der PIDs nicht neu getunt wird und die Aufnahme daher schiefgeht.


    Wenn da tatsächlich die PIDs aktualisiert werden, ohne daß das im Transponder-Datenstrom so vorkommt, dann müsste vielleicht mal jemand genauer untersuchen, woran das liegt.


    Klaus


    Hier mal der Versuch, das zu realisieren:


    Getestet habe ich das nicht, weil ich nur den DVB-EPG verwende.
    Also bitte ausprobieren und Bescheid geben, ob das so in Ordnung wäre.


    Klaus


    Andererseits ist Das Thema "vernünftiges EPG" ja auch nicht neu und dich denke mal, dass es dafür für den VDR wohl nie eine für alle befriedigende Lösung geben wird.


    VDR arbeitet mit den Informationen, die ihm gemäß dem DVB-Standard von den Sendern zur Verfügung gestellt werden. Wem das nicht "vernünftig" erscheint, der möge sich doch mal bei den Sendeanstalten beschweren. Die hätten es ja ohne weiteres in der Hand, all die gewünschten Informationen in ihrem EPG unterzubringen.


    VDR ist nur der "Überbringer" der (schlechten) Nachricht ;)


    Klaus

    Sollte natürlich so sein:


    0x03: ( Title_ext-EPG != Title_DVB-EPG ) && DVB-EPG


    Wenn der Titel von ext-EPG abweicht, dann nimm das komplette EPG von DVB. ;)


    Ich sehe schon, das wird wieder beliebig kompliziert ;)
    Ich bleibe dabei: entweder der EPG vom Sender (Table-IDs nach DVB-Standard, also 0x4E...0x6F) oder der von "außen".
    Ich möchte nicht, daß VDR einen von außen eingespeisten EPG dann doch wieder überschreibt, oder vielleicht auch wieder nicht, je nach Windrichtung am Wendelstein etc... ;)


    Klaus


    An die EPG-Mischer (zu denen ich mich auch zählen würde, auch wenn ich es momentan noch nicht tue):
    Der Hauptgrund zum Mischen sind doch meistens "nur" bessere Beschreibungen und Episodentitel, oder?
    Was helfen würde, wäre eine feinere Steuerung, was der vdr an einem Event überschreiben darf. Sprich, wenn man mal den Titel, Untertitel und Beschreibung aktualisiert hat, dann soll der vdr nur noch den Rest wie Startzeit usw. aktualisieren.


    Da es ja noch jede Menge unbenutzte Table-IDs gibt, ließe sich das ja vielleicht dadurch erreichen, daß man solche Events mit einer anderen Table-ID markiert.


    Wie wäre es denn damit:


    - Die jüngste Änderung, daß ein erster Event in der Liste mit ID 0x00 dazu führt, daß VDR die gesamte Liste unberührt läßt, wird wieder zurückgenommen. Damit wäre wieder alles, wie vorher.


    - 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


    (**) wegen "running status" etc. muß das noch etwas anders gehandhabt werden als jetzt in 1.7.25 für 0x00.


    Klaus


    Ich vermute, daß da noch ein Problem ist, wenn es nur gebondete Devices gibt und ein EPG-Scan einsetzt oder auf Timer-Transponder geschaltet werden soll.
    Werd's mir anschauen.


    Klaus


    Vielleicht kennt Vanilla VDR ja auch das Problem nicht ? Benutzt das jemand (und kennt die Probleme) ?


    Ich konnte hier nachvollziehen, daß nach einem CLRE (ohne Kanalangabe, also "alles") und unmittelbar nachfolgendem LSTE die Liste noch voll war. Nach der jüngsten Änderung, die ich gepostet habe, war das dann weg. Somit könnte das durchaus einige Probleme lösen.


    Klaus

    Sorry, der Patch von vorhin war leider nicht ganz richtig.
    Hier nochmal:


    Klaus

    [...]
    Wenn der VDR durchläuft, dann ist das kein Problem, nur wenn der VDR mal neu gestartet wird, dann "vergisst" er, dass er die Evensts mit id 0 nicht anfassen soll.


    Dieses "Vergessen" könnte ich mir höchstens bei einem unkontrollierten Absturz erklären, wenn seit dem letzten PUTE die EPG-Daten noch nicht auf die Platte geschrieben wurden (was alle 10 Minuten passiert).
    Wenn VDR normal beendet wird, dann werden die EPG-Daten auf alle Fälle geschrieben.


    Kannst du eine reproduzierbare Vorgehensweise angeben, bei der das nicht wie erwartet funktioniert?


    Klaus

    Das remote Plugin hat damit nix zu tun. Bei dem rcu gehts ja um die Steuerung mit nem selbstbau IR Empfänger.


    So wie es aussieht wurde einfach der rcu Teil (den vermutlich eh nur noch sehr wenige Nutzen) in ein Plugin ausgelagert. Diese Änderung sollte also nur sehr wenige Betreffen.


    Genau so ist es.


    Klaus

    Eine These wäre evtl. das die verkettete Liste durcheinanderkommt wenn man CLRE macht und Timer gesetzt werden, weil die Einträge die einen Timer haben nicht gelöscht werden.


    Das wurde in Version 1.7.23 korrigiert. Seitdem löscht auch ein CLRE für einen einzelnen Kanal die Events, die mit einem Timer verknüpft sind.


    Klaus

    Vllt wäre es ne Lösung wenn er nach einem CLRE für eine bestimmte Zeit keine Daten vom Transponder nimmt damit das sauber bleibt...?


    Das ist doch schon der Fall:


    Code
    help clre
    214-CLRE [ <number> | <name> | <id> ]
    214-    Clear the EPG list of the given channel number, name or id.
    214-    Without option it clears the entire EPG list.
    214-    After a CLRE command, no further EPG processing is done for 10
    214-    seconds, so that data sent with subsequent PUTE commands doesn't
    214-    interfere with data from the broadcasters.
    214 End of HELP info


    Allerdings sehe ich da jetzt bei genauerer Betrachtung durchaus eine Lücke, wenn nicht der EPG eines einzelnen Kanals mit CLRE gelöscht wird, sondern alle EPG-Daten:


    Code
    else {
         cSchedules::ClearAll();
         cEitFilter::SetDisableUntil(time(NULL) + EITDISABLETIME);
         Reply(250, "EPG data cleared");
         }


    In der kurzen Zeit zwischen dem ClearAll() und SetDisableUntil() könnten theoretisch Daten vom Transponder kommen, denn der cSchedulesLock greift ja nur innerhalb ClearAll().
    Außerdem könnten die 10 Sekunden abgelaufen sein, wenn sehr viele EPG-Daten einzulesen sind, da die über SVDRP übergebenen Daten erst in einer Datei zwischengespeichert und dann am Ende des PUTE-Befehls komplett an cSchedules::Read() übergeben werden. Daher sollte wohl nach jeder eingelesenen Zeile der Timeout neu aufgezogen werden.


    Könnt ihr bitte mal folgendes testen:



    Damit sollte es jetzt möglich sein, EPG-Daten einzulesen ohne daß Transponderdaten "dazwischenfunken" können.


    Falls sehr viele EPG-Daten von unterschiedlichen Kanälen eingelesen werden sollen, empfehle ich, dies für jeden Kanal einzeln zu tun. Also erst ein CLRE mit der ChannelID des Kanals, und dann mit PUTE die Daten für genau diesen Kanal. Dann ist die Hauptschleife nicht zu lange blockiert.


    Klaus

    Nur mal so aus reiner Neugier: Was war denn der Anlass hierfür? Viel schwer zu wartenden Code loswerden? Oder...?


    Derek Kelly (user.vdr@gmail.com) lag mir ständig in den Ohren wegen des EPG in Amerika, den die anscheinend aus externen Quellen beziehen, und der immer wieder mit dem aus dem DVB-Datenstrom kollidierte. Daher diese Änderung, mit der man den extern eingespeisten EPG so gestalten kann, daß VDR ihn vollkommen in Ruhe lässt.


    Klaus

    Mischen tue ich hier auch nicht - da der Key ja nur die Sendezeit ist gibt mir das zu schnell Duplikate. Augenscheinlich mischen hier aber andere.


    Ganz richtig ist es auch nicht - DVB EPG Daten kann ich dann nicht extern mit einfliessen lassen - da ich sie nicht mehr bekomme - in MEINER persönlichen Anwendung kommt das auch so nicht vor. Ich benutze momentan noEPG noch. also für MICH völlig ok.


    Wie gesagt, wenn du schon eine externe Quelle für den EPG hast, dann doch bitte alles von dort beziehen ;)


    Zitat


    Der zweite Absatz den du von mir zitiert hast, hast du ja nicht weiter angesprochen - von sofern lass ich das mal so stehen (hat auch nur indirekt mit diesem Thema zu tun)


    Sorry, den hätte ich wohl löschen sollen ;)


    Klaus

    Was passiert denn, wenn man einen Eintrag mit PUTE ändert? Wird dann für alle späteren EPG-Events kein EPG mehr vom DVB-Stream eingelesen? Oder gilt das nur für diesen einen Event?


    Sobald der erste Event in der Liste eines Kanals (wobei die Events nach Startzeit sortiert sind) eine Table-ID von 0x00 hat lässt VDR diese Liste so lange komplett in Ruhe, bis alle "veralteten" Events verschwunden sind und der erste Event in der LIste wieder eine Table-ID ungleich 0x00 hat.


    Klaus

    Ich verstehe es so das, wenn man CLRE und dann PUTE macht, das man dann eine Wahrscheinlichkeit von 100% hat das der erste Eintrag eine table id 0 hat. Evtl funktionieren diese Merge Lösungen ja auch weiterhin ? Besser als NoEPG ist es so aber alle mal, da man so wenn das externe EPG nichts liefert entweder irgendwann automatisch wieder EPG bekommt oder es mit CLRE forcieren kann. Man bekommt so also wenn das externe EPG einen Fehler hat wieder Sender EPG.


    Meine Traumvorstellung wäre das man das EPG in einer externen Instanz (wie auch immer die aussieht) liegen hat und der VDR das sowohl abfragen als auch füttern kann. In einem für mich normalen Setup gibt es immer 2-3 Programme die das EPG des VDR synchronisieren (z.B. xbmc) , ausserdem gefiele mir daran, das man extern zum VDR die Einträge konkret ändern könnte. (Also z.B. ein update auf bestimmte Einträge machen könnte) Wenn man mehrere VDRs hätte könnte man 1 EPG pflegen und es wäre in allen Instanzen im Haushalt sauber. XBMC könnte sofort die Informationen abfragen. Für den Otto-Normal-VDR-User kann ja gerne die jetzige Funktionsweise erhalten bleiben, aber wenn man das über ein Plugin ersetzen könnte wäre es Klasse.


    Du kannst den EPG jetzt komplett außerhalb von VDR verwalten, aus beliebigen Quellen holen etc., etc. Wenn du deinen EPG so beisammen hast, wie er dir gefällt, dann machst du CLRE für den betreffenden Kanal und schiebst deine EPG-Daten mit PUTE und Table-ID 0x00 rein. Damit läßt VDR für diesen Kanal den EPG komplett in Ruhe und du hast genau das, was du sehen willst.


    Entweder benutzt VDR den EPG vom Sender (die bevorzugte Methode, weil so auch VPS funktioniert, falls der Sender es unterstutzt, und der EPG mitunter auch aktueller ist), oder er kommt komplett von "außen". Von einer "Mischung" halte ich nichts.


    Klaus