[gelöst ] Herausfinden, ob es neue/geänderte EPG Einträge gibt

  • Hallo,


    kann ich (genauer: das plugin tvscraper) herausfinden, ob es neue EPG Einträge gibt?

    Derzeit macht das Plugin einen täglichen Update. Das ist zu wenig :( . Ich kann das jetzt natürlich öfter machen.

    Aber eigentlich wäre es optimal, immer dann, wenn es neue oder geänderte Einträge im EPG gibt, auch ein tvscraper Update durchzuführen.


    ~ 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

  • Schau dir mal cMenuSchedule::Set() an. schedulesStateKey wird im Aufruf von cSchedules::GetSchedulesRead(schedulesStateKey) übergeben, so dass nur dann true zurückgeliefert wird, wenn sich am EPG etwas geändert hat. Das betrifft aber auch jegliche Statusänderungen, kommt also durchaus öfter vor.

  • Danke, Klaus :).

    Funktioniert bei mir vermutlich noch nicht ganz.

    • Ich loope über alle Kanäle, die ich scrapen möchte.
    • Dann LOCK_CHANNELS_READ; *channel = Channels->GetByChannelID
    • Dann const cSchedules *Schedules = cSchedules::GetSchedulesRead(schedulesStateKey);
    • Dann, falls (Schedules), scrape ich den Kanal, und rufe danach schedulesStateKey.Remove();
    • Dann weiter mit dem nächsten Kanal

    Es sieht so aus, dass höchstens der Erste Kanal gescraped wird :(.

    Wie muss ich das ändern?


    ~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

  • Du solltest zuerst cSchedules::GetSchedulesRead(schedulesStateKey) aufrufen und wenn das einen Pointer liefert, dann durch die Kanäle gehen und sie scrapen. Erst nachdem du alle gewünschten Kanäle gescraped hast, solltest du schedulesStateKey.Remove() aufrufen.

  • Danke, Klaus!


    Ich habe das umgebaut, und das funktioniert jetzt.

    Noch 2 Fragen:

    - Wie häufig gibt es solche Änderungen im "normalen" Dauerbetrieb, also wenn der VDR schon eine Zeit lang läuft? So etwa?

    - Ist es ein Problem, wenn Channels & Schedules für die gesamte Zeit des Scrapens gelockt bleiben (Lese-Lock)? Das dauert normalerweise etwa 2-10 Minuten, kann aber auch sehr deutlich länger dauern, wenn der Cache erst aufgebaut werden muss.


    ~ 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

  • - Wie häufig gibt es solche Änderungen im "normalen" Dauerbetrieb, also wenn der VDR schon eine Zeit lang läuft? So etwa?

    Jedes Mal, wenn sich der Status einer Sendung ändert, und ansonsten schätzungsweise alle paar Stunden pro Kanal.


    Ist es ein Problem, wenn Channels & Schedules für die gesamte Zeit des Scrapens gelockt bleiben

    Ja, das könnte problematisch sein. Solche Locks sollten so kurz wie möglich sein. Merk dir doch einfach, dass es eine Änderung gegeben hat, gib den Lock wieder auf und scrape dann (ohne permanenten Lock).

  • Hi,


    Ich habe mal getestet:

    • const cSchedules *Schedules = cSchedules::GetSchedulesRead(schedulesStateKey); alle 15 min aufrufen.
    • Und prüfen, ob Schedules == 0.

    Nach einem Tag war Schedules insgesamt 2 mal null. Es hat sich in den 15 min also (fast) immer etwas geändert.

    Wie kann ich herausfinden, was sich geändert hat?


    ~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

  • Vielleicht trivial, aber meine Beobachtung bei den üblichen deutschen FTA-Kanälen ist:

    "Neue" EPG-Einträge gibt es typischer Weise einmal täglich morgens um 6. Dabei wird ein kompletter neuer Tag angehängt.

    Über den Tag wirft der VDR veraltete Events nach und nach raus.

    Wirkliche Änderungen/Aktualisierungen treten eher selten auf (bei vielen Sendern auch nie).

    Ausnahme Now/Next-Event für die laufende/nächste Sendung, die ändern sich ständig.


    Ich weiss zwar nicht genau, wie das intern abläuft, aber auf irgendeine dieser Änderungen wird die Abfrage wohl ansprechen.


    Sofern niemand eine bessere Idee hat, wird man wohl die einzelnen Events vergleichen müssen, befürchte ich.

    Gruss
    SHF


  • Hi,


    Ich merke mir jetzt die Events in

    map<string, set<int>*> lastEvents;

    String ist der Kanal, und in dem set stehen die Event IDs.

    Dann kann ich die neuen Events mit den Alten vergleichen.


    ~ 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