VPS und EpgHandlers.HandledExternally(Channel);

  • Ja, so ist das wohl, macht ja auch Sinn, um sicher zu verhindern, dass nicht zwei Plugins den Event ändern.

  • Vielleicht fehlt in Plugins.html ein Hinweis, die Event-IDs nicht zu verändern.

  • kfb77 , anbei ein (sehr kleines) Update des vps.epg2vdr.txt Patches. Damit gibt HandleEvent immer false zurück, und damit sollten auch immer die anderen Plugins gerufen werden, die HandleEvent implementieren.

    Bitte testen. Ich denke aber nicht, dass das zu Problemen führt. HIer gilt das Highlander Prinzip. Also nur EIN Plugin verändert das EPG. Sonst geht bestimmt irgend etwas schief .. Steht schon den der Readme des Plugins.

  • Vielleicht fehlt in Plugins.html ein Hinweis, die Event-IDs nicht zu verändern.

    Diff
    --- epg.h       2021/04/28 20:44:56     5.2
    +++ epg.h       2022/12/24 11:32:23
    @@ -274,6 +274,7 @@
               ///< therefore the EPG handlers have to take care of this. Otherwise the parsing of
               ///< non-updates will waste a lot of resources.
       virtual bool SetEventID(cEvent *Event, tEventID EventID) { return false; }
    +          ///< Important note: if you want VPS to work, do not mess with the event ids!
       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; }
  • Hi,


    Also, der vps.epg2vdr.txt ist so nicht zwingend, den kann man bestimmt auch anders machen.


    Ich könnte epg2vdr so patchen, dass nur Events erzeugt werden, für die es auch EIT Events gibt. Dann könnte epg2vdr immer die EIT Event ID verwenden.

    Dann könnte epg2vdr einfach nur EpgHandlers.SetDescription(pEvent, rEvent->Description()); implementieren, und in der Beschreibung Informationen aus dem externen EPG ergänzen. Alle anderen EpgHandlers Schnittstellen würden nicht mehr verwendet werden. Außer ev. EpgHandlers.StarSegmentTransfer / EpgHandlers.EndSegmentTransfer . Und VPS würde funktionieren, wie ohne das Plugin ...


    Also, wir hätten dann einen Klon vom epg2vdr Plugin, und Anwender können entscheiden, ob sie den Klon (mit eingeschränkter Funktionalität, wie oben beschrieben) verwenden. Oder das Original, aber halt dann ohne VPS ...


    Ich frage jetzt mal in die Runde: Was haltet ihr von diese Idee?


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Alle anderen EpgHandlers Schnittstellen würden nicht mehr verwendet werden.

    Den Ansatz habe ich noch nicht verstanden: Ja, dann würden Plugins aufgerufen werden, die dann aber nichts ändern dürfen. Wie kann man das sicherstellen ?

    Und was macht dann der VDR selbst ? Ich vermute, HandledExternally müsste schon true sein, um den VDR selbst davon abzuhalten Änderungen zu machen. Aber wird dann noch HandleEvent aufgerufen ?

  • Ich könnte epg2vdr so patchen, dass nur Events erzeugt werden, für die es auch EIT Events gibt. Dann könnte epg2vdr immer die EIT Event ID verwenden.

    Die Event-IDs von EIT sind 16 Bit, VDR speichert 32 Bit. Du könntest also für Events, die (noch) nicht vom EIT kommen, eigene IDs verwenden, die ausserhalb des 16 Bit Bereichs liegen. Dass die IDs mit denen aus EIT übereinstimmen wird erst wirklich wichtig, wenn die Startzeit sich nähert.

  • MarkusE

    Vielen Dank, damit ruft mich der VDR bei einem Event auf. Das werde ich so in mein Plugin epg2vdr übernehmen und markad entsprechend anpassen. Das wäre dann auch problemlos abwärtskompatibel, wenn der Patch nicht drin ist, geht es eben nicht.

    wir hätten dann einen Klon vom epg2vdr Plugin

    Das finde ich nicht gut, besser wäre es, wenn es horchi übernehmen würde. Versuche es doch mal mit einem Pull request.

  • damit ruft mich der VDR bei einem Event auf.

    Ich muss mich korrigieren, es geht doch nicht. Ich hatte den Event vom SD Kanal bekommen, der nicht in der channelmap ist.

  • Die Event-IDs von EIT sind 16 Bit, VDR speichert 32 Bit. Du könntest also für Events, die (noch) nicht vom EIT kommen, eigene IDs verwenden, die ausserhalb des 16 Bit Bereichs liegen. Dass die IDs mit denen aus EIT übereinstimmen wird erst wirklich wichtig, wenn die Startzeit sich nähert.

    Hm,


    Dann würde sich die Event ID eines Events über die Zeit ändern: Zunächst eigene Event ID, wenn es noch kein EIT Event gibt. Später dann die EIT Event ID.

    Würde wohl gehen. Verursacht kleinere Probleme bei live und tvscraper:

    • Live verwendet die Event IDs in Links. Wenn also eine Übersichtsseite gebaut wird, sich dann die Event ID ändert, und dann der Anwender auf den Link zur Detailanzeige des Events clickt, gibt es keine Daten
    • Tvscraper verwendet auch die Event IDs, um Events zu identifizieren. Wenn die Event ID nicht mehr passt, wird neu gescraped, mit Daten aus dem Cache. Passiert relativ häufig, so ca. alle 10 min. Wenn dann der Anwender Bilder zu dem Event sehen will, wundert er sich, warum das Bild gerade eben noch da war. Und jetzt verschwunden ist. In 10 min ist es dann wieder da.


    Also, das überzeugt mich jetzt nicht. Ob es in anderen Plugins auch zu Problemen führt, kann ich nicht sagen, die kenne ich nicht so genau.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.6x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • Ich muss mich korrigieren, es geht doch nicht. Ich hatte den Event vom SD Kanal bekommen, der nicht in der channelmap ist.

    Hi,


    Bitte teste mal mit den 2 neuen Patches.


    ~ Markus

  • Ist drin und zusätzlich habe ich an beiden Plugins (markad und epg2vdr) bei HandleEvent zusätzlich Debug Meldungen eingebaut.

    Bei beiden kommt nichts an.

  • FireFly Steht in vdr.5:


    Note that the event id that comes from the DVB data stream is actually

    just 16 bit wide. The internal representation in VDR allows for 32 bit to

    be used, so that external tools can generate EPG data that is guaranteed

    not to collide with the ids of existing data.

  • horchi


    würdest Du diese Änderung mal mit ansehen und einpflegen? Du wurdest ja schon mehrfach "erwähnt" jedoch kam bisher dazu kein Statement, wäre schön wenn es im Bezug auf VPS eine Lösung geben würde - Danke ;)

    Gruß utiltiy



    VDR Projects

  • Ich schaue es mir bei Gelegenheit gern an

    horchi: Konntest du da schon eine Gelegenheit finden?


    Danke schon mal!

  • habe es mir angesehen, der Umbau ist nicht ganz klein.

    Das Plugin ist so aufgebaut das es eine Event Quelle ist, die DVB Events werden abgegriffen und in einer Datenbank abgelegt, sie gelangen nicht ins EPG. In der Datenbank werden sie mit EPG Daten aus bis zu zwei weiteren EPG Quellen gemerged und damit neue Events erstellt welche auf diesem Weg aktuell gehalten werden. Diese Events werden in das EPG übernommen.

    Das hätte man auch anderes aufbauen können, damals erschien es als best mögliche Lösung, auch zu dem Damaligen Stand des EPG Handler Interfaces.


    Um es nun umzubauen muss das Handling der IDs umgebaut werden, also die Stelle an welcher alles zusammen läuft.

    Ich werde das mal mit CKone durchsprechen ggf. fällt uns eine pragmatische Lösung ein, für einen großen Umbau habe ich im Moment keine Zeit.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!