[VDR-2.6.0 + epgsearch] Vermeide Wiederholung

  • Hallo,


    bei mir geht schon seit geraumer Zeit "Vermeide Wiederholung" von epgsearch nicht mehr.

    Es sieht so aus, das dieser Effekt seit VDR 2.5.3 oder 2.5.4 auftritt.

    Bevor ich jetzt hier auf Fehlersuche gehe, würde ich gern wissen, ob das bei Nutzern, die schon VDR-2.6.0 einsetzen, noch richtig funktioniert.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich habe am Dienstag folgende Beobachtung gemacht:


    Ich habe searchtimer für "Navy CIS", "NCIS: LosAngeles" und "Bull" in epgsearch unter 2.6.0. Als ich mir um ca. 18:00 h die Timerliste angesehen habe, waren die vier Timer ab 20:10 drin. Der nächste Timer war definitiv erst am Mittwoch um 18:00 - die nächtlichen Wiederholungen der vier Timer waren NICHT in der Timerliste. Am nächsten Tag habe ich acht Aufnahmen gefunden, so als ob mit den ersten vier Aufnahmen etwas falsch gelaufen war (so wie bei abgebrochenen Aufnahmen, vdr Abstürzen oder Empfangsprobleme), und die Wiederholungen dann wieder aufgenommen wurden - nur waren alle Aufnahmen soweit ich sehen konnte ok. Könnze das mit der neuen vdr Funktion für erkennen von beschädigten Aufnahmen zusammenhängen? So dass epgsearch denkt es müsse nochmal aufnehmen?

  • @nvertigo ,


    so ist das bei mir auch. Soweit ich das bisher gesehen habe, werden die fertigen Aufnahmen nicht mehr in die "epgsearchdone.data" eingetragen.

    Könnze das mit der neuen vdr Funktion für erkennen von beschädigten Aufnahmen zusammenhängen? So dass epgsearch denkt es müsse nochmal aufnehmen?

    Das glaube ich nicht, da das noch nicht von epgsearch ausgewertet wird. Bei mir ist das auch unabhängig davon, ob eine Aufnahme Fehler hat oder nicht.


    Dann bin ich wohl nicht der Einzige mit diesem Problem.

    TomJoad , vielleicht kannst Du Dir das mal ansehen.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Vllt. im Konflikt mit Pattern Timer, einer neuen Funktion seit 2.5.x?

    HowTo: APT pinning

  • Das ist durchaus möglich, da hat sich bestimmt das Timer-Handling etwas geändert.


    Vor einiger Zeit hatte ich mal ein paar Debug-Meldungen in epgsearch recdone_thread.c eingebaut. Da ist auffällig, das der betrachtete Timer bereits gelöscht war, bevor dieser thread aktiv wurde und es dadurch keinen Fall positiv gab:

    Code
    Jan 06 17:02:00 vdr[510457]: [510457] timer 21 (3 1609-1702 'Serien~Die Rosenheim-Cops~Ausgebacken') set to no event
    Jan 06 17:02:00 vdr[510457]: [510457] deleting timer 21 (3 1609-1702 'Serien~Die Rosenheim-Cops~Ausgebacken')
    Jan 06 17:02:00 vdr[510457]: [602284] recdone_thread.c Action 80 - started recdone_thread
    Jan 06 17:02:00 vdr[510457]: [602284] recdone_thread.c Action 90 processing /Video/video0/Serien/Die_Rosenheim-Cops/Ausgebacken/2022-01-06.16.09.3-0.rec

    Ich weiß aber nicht, wie das vorher war und weiter verfolgt habe ich es bisher nicht.


    Na mal sehen.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • @nvertigo ,


    so ist das bei mir auch. Soweit ich das bisher gesehen habe, werden die fertigen Aufnahmen nicht mehr in die "epgsearchdone.data" eingetragen.

    Das glaube ich nicht, da das noch nicht von epgsearch ausgewertet wird. Bei mir ist das auch unabhängig davon, ob eine Aufnahme Fehler hat oder nicht.

    Wie gesagt, es ist bei mir auch unabhängig von Fehlern (alle acht Aufnahmen waren ok). Ich wollte nur sagen, dass ich dieses Verhalten (Aufnahme nicht in epgsearchdone.data eingetragen) von <=2.4.8 nur kenne, wenn die Aufnahme Fehler hatte.

  • Ich wollte nur sagen, dass ich dieses Verhalten (Aufnahme nicht in epgsearchdone.data eingetragen) von <=2.4.8 nur kenne, wenn die Aufnahme Fehler hatte.

    Ja, so kenne ich das auch. Erst ab 2.5.x klappt das bei mir nicht mehr.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Werde ich mir ansehen, was steht denn in der epgsearch.log?

    Richtig wäre bei von Searchtimern erzeugten Timern nach Aufnahmeende:

    finished: 'titel' ....

    added rec done for ...


    Hängt aber wahrscheinlich wirklich mit 2.5/2.6 zusammen und mit dem commit:

    Author: Klaus Schmidinger <vdr@tvdr.de>

    Date: Tue Apr 20 13:22:37 2021 +0200
    Deleting expired timers is now triggered immediately after the timers are modified

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

    Edited once, last by TomJoad ().

  • bei mir sieht das so aus. Aufnahme war i.O.

    Code
    Do. 06.01.2022 19:15:00: started recdone_thread
    Do. 06.01.2022 19:15:00: recdone_thread processing /sicherungsdaten/vdrserver//Serien/SOKO_Stuttgart/Staffel_13/15._-_Mord_an_Bord/2022-01-06.17.55.2-0.rec
    Do. 06.01.2022 19:15:00: recdone_thread ended
    Do. 06.01.2022 19:37:00: search timer update started
    Do. 06.01.2022 19:37:05: added timer for 'SOKO Stuttgart~Mord an Bord' (Fr. 07.01.2022 - 02:55); search timer: 'SOKO Stuttgart'
    Do. 06.01.2022 19:37:06: search timer update finished

    VDR 4: AMD Kabini 5310, Asrock AM1H-ITX, Gen2Vdr V6, Cine S2, Atric , Harmony 515 , Streacom ST-F7CB EVO

  • Hängt aber wahrscheinlich wirklich mit 2.5/2.6 zusammen und mit dem commit:

    Author: Klaus Schmidinger <vdr@tvdr.de>

    Date: Tue Apr 20 13:22:37 2021 +0200
    Deleting expired timers is now triggered immediately after the timers are modified

    Das ist das verantwortliche commit. Ich habe das mal reverted und siehe da, es funktioniert wieder:

    Code
    Fr. 07.01.2022 13:12:00: started recdone_thread
    Fr. 07.01.2022 13:12:00: recdone_thread processing /Video/video0/Serien/Castle/Dem_Dreifachmörder_auf_der_Spur/2022-01-07.12.23.57-0.rec
    Fr. 07.01.2022 13:12:00: finished: 'Serien~Castle~Dem Dreifachmörder auf der Spur'; search timer: 'Castle'; VPS used: No
    Fr. 07.01.2022 13:12:00: added rec done for 'Castle~Dem Dreifachmörder auf der Spur';Castle
    Fr. 07.01.2022 13:12:00: recdone_thread ended

    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ah. Hab mich an das Versagen der Wiederholungserkennung seit 2.5 bereits gewöhnt und benütze jetzt regelmäßig die neue Funktion in "live", um auszumisten :)

  • Ich habe mal hier etwas weiter experimentiert, auch weil ich nicht abschätzen kann, wie umfangreich eine Anpassung in epgsearch werden könnte.

    Hängt aber wahrscheinlich wirklich mit 2.5/2.6 zusammen und mit dem commit:

    Author: Klaus Schmidinger <vdr@tvdr.de>

    Date: Tue Apr 20 13:22:37 2021 +0200
    Deleting expired timers is now triggered immediately after the timers are modified

    Ob dieser commit funktional bedingt war, kann sicher nur kls mit Bestimmtheit sagen.


    Ich habe deshalb testhalber die Funktion "bool cTimers::DeleteExpired(bool Force)" auch für den Fall "Forced" mit einer Verzögerung von 1s versehen, um das nicht unnötig lange zu verzögern. Dadurch hat epgsearch genügend Zeit, um den recdone thread abzuarbeiten. Auch damit funktioniert es problemlos.

    Siehe Anhang: cTimers.DeleteExpired.diff.gz


    Bei dieser Gelegenheit (und weil es zu "Vermeide Wiederholung" passt) habe ich den "recdone_thread" um die Prüfung der fehlerfreien Aufnahme erweitert.

    Siehe Anhang: 0001-Add-check-errors-to-recdone_thread.c.patch.gz

    Damit wird eine Aufnahme nur dann als "erledigt" markiert, wenn keine Fehler vorhanden sind.:)

    TomJoad , vielleicht kannst Du das so oder ähnlich mit in epgsearch aufnehmen.


    Grüße

    kamel5

  • Test läuft ab heute :)

  • Ob dieser commit funktional bedingt war, kann sicher nur kls mit Bestimmtheit sagen.


    Ich habe deshalb testhalber die Funktion "bool cTimers::DeleteExpired(bool Force)" auch für den Fall "Forced" mit einer Verzögerung von 1s versehen, um das nicht unnötig lange zu verzögern. Dadurch hat epgsearch genügend Zeit, um den recdone thread abzuarbeiten. Auch damit funktioniert es problemlos.

    Siehe Anhang: cTimers.DeleteExpired.diff.gz

    Ich hatte mit dem revert zwei Abstürze in 18 h. Dein Patch läuft jetzt seit 17 h, kein Absturz und Aufnahmen landen in epgsearchdone.data.


    Deinen zweiten Patch habe ich auch drin, aber noch keine kaputte Aufnahme.


    Vielen Dank!

  • Ich teste gerade, die Start- und Stopzeiten des Timers zu Beginn der Aufnahme in der recdone-Struktur abzulegen. Falls bei Aufnahmeende der timer nicht mehr verfügbar ist, wird auf diese Werte zurückgegriffen. Damit ist man unabhängig davon, wie lange vdr die timer-Struktur erhält.

    Die Mitbewertung der errors in vdr 2.6 hatte ich auch in der Pipeline, ich würde nur gerne die Anzahl der tolerierten Fehler konfigurierbar machen.

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

  • TomJoad


    Nicht eilig, dringend oder wichtig (verglichen mit Wiederholungsvermeidung), aber wenn Du mal eine ruhige Minute hast, könntest Du Dor vieleicht mal "Zeige erstellte Timer" in Skindesigner Skins ansehen: währen "Zeige erledigte Aufnahmen" eine schöne Liste ausgibt, wird bei "Zeige erstellte Timer" die Kopfzeile zwar richtig angezeigt, aber die Liste scheint leer (ich schreibe "scheint", weil die Einträge da sind: man kann sie auswählen und z.B. löschen - nur sieht man sie nicht. Oder ost das ein Skindesigner-Problem?

  • Vielleicht mag ja jemand den angehängten Patch testen, bevor er ins git kommt.

    Damit dürfen timer schon gelöscht sein, wenn das Aufnahmeende untersucht wird.

    Sollte mit vdr 2.4 und 2.6 funktionieren.

    epgsearch-changed-handling-of-finished-recordings.patch

    vdr-2.7.3

    softhddevice, dbus2vdr, dvd, epgsearch, femon, graphtftng, web, menuorg,
    osdteletext, radio, recsearch, satip, tvguide, vnsiserver

    ubuntu focal, yavdr-ansible, linux-5.15 ,AsRock J4105, CIne CT-V7 DVB-C

  • Ich hatte auch Probleme mit dem Einspielen des Patches. Ein reject in recdone_thread.c (erster Patch-Teil).

    Nach händischer Auflösung und kurzem Test muss ich leider feststellen, das es bisher nicht wie erwartet funktioniert hat, trotz ordnungsgemäßer Aufnahme.

    Weitere Tests kann ich erst in den nächsten Tagen machen.


    Grüße

    kamel5

    VDR 2.7.3: ASUS Prime X470-PRO, Ryzen 7 5700X, 64GB, 6TB HD, GT1030, Fedora 40 Kernel 6.11 X86_64, Devicebonding 2 x 1 auf 2, TT6400, DVBSky S952 V3

    Git-Repo: gitlab.com/kamel5

  • Ich hatte auch Probleme mit dem Einspielen des Patches. Ein reject in recdone_thread.c (erster Patch-Teil).

    Evtl. ist ja der Unterschied, der den patch (btw: und "git am") rejecten läßt, genau das, was ihn nicht funktionieren läßt?


    Ich habe mit dem händisch einbauen die gleiche Erfahrung gemacht (dass der patch nicht funktioniert), hatte aber eher mein händisches Einbauen in Verdacht, als den Patch selbst... ;)

Participate now!

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