[VDR-2.6.0 + epgsearch] Vermeide Wiederholung

    Jau, v2 past. Ob's funktioniert kann ich Dir gegen 22h nach der Tatort-Serien-Aufnahme sagen.


    EDIT:


    Funktioniert leider nicht - es wird sofort die Tatort-Aufnahme auf oneHD gestartet, welche einen Timer-Konflikt erzeugt. Wenn ich versuche den neu erzeugten Timer zu löschen, crasht der vdr:


    Ich habe hier auch ein epgsearch.log (Stufe 2 - vdr crasht immer, wenn ich den Timer lösche, manuell als bereits aufgenommen kennzeichnen ändert daran nichts):

    Den Crash kann ich bestätigen:

    Allerdings trat das bei mir nur manchmal auf. Bisher konnte ich das nur reproduzieren, wenn ich während einer bereits laufenden SuchTimer-Aufnahme die Endezeit vorgezogen habe (im Bereich des Timernachlaufs). Ein Löschen von SuchTimern habe ich noch nicht probiert.


    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

    Like 1

    Danke fürs Testen, ich kann das zwar bei mir nicht nachvollziehen, habe aber eine Umstellung gemacht, die den crash verhindern sollte.

    Ausserdem werden mehr logs mit Loglevel 2 statt 3 geschrieben.

    Quote from TomJoad

    Danke fürs Testen, ich kann das zwar bei mir nicht nachvollziehen, habe aber eine Umstellung gemacht, die den crash verhindern sollte.

    Ausserdem werden mehr logs mit Loglevel 2 statt 3 geschrieben.

    Könnte die unterschiedliche source-code basis der Grund sein, warum Du das bei Dir nicht reproduzieren kannst?

    Code
    patch -p1 --no-backup-if-mismatch --dry-run </mnt/export/data/Downloads/incoming/epgsearch-changed-handling-of-finished-recs-v3.patch
checking file menu_commands.c
checking file recdone.c
checking file recdone.h
checking file recdone_thread.c
Hunk #1 FAILED at 80.
Hunk #2 succeeded at 149 (offset 10 lines).
1 out of 2 hunks FAILED
checking file recstatus.c

    Bei mir ließ sich der letzte Patch problemlos einspielen, auf letzten git-Stand.


    Ich habe den VDR gerade aktualisiert, mal sehen, was mit der nächsten Aufnahme passiert.


    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

    Oh, ja, Du hast recht.ich hatte Deinen "Add check errors to recdone_thread.c" commit noch drin. TomJoad: Sorry.

    Bei mir läuft v3 seit gestern 18:30 Uhr. Heute Nacht lief die Aufnahme (Bosetti; Timerstart 18.1.2022 01:30 h) eines epgsearch Serien-Timers. epgsearch.log beginnt um So. 16.01.2022 19:21:32.


    Code
    grep "added rec done for" /etc/vdr/plugins/epgsearch/epgsearch.log
Mo. 17.01.2022 05:22:00: added rec done for 'Inspector Barnaby~Der Stachel des Todes';Inspector Barnaby
Mo. 17.01.2022 15:00:00: added rec done for 'Elementary~Kampfhähne';Elementary

    Einen Crash konnte ich mit v3 bisher nicht beobachten, aber "added rec done for" gibts für den Timer nicht. Der Bosetti-Timer hatte "vermeide Wiederholungen" nicht gesetzt, aber der "added rec done for"-Eintrag hätte doch trotzdem erscheinen müssen, oder nicht? Heute Mittag habe ich einen Serientimer mit "vermeide Wiederholungen" (Elementary) und einer Woederholung der Folge morgen früh - ich berichte nach Ende der Aufnahme, ob epgsearch mit v3 ein zweites mal auf die Wiederholung anspringt, aber ich befürchte, es funktioniert noch nicht.

    @nvertigo: Die komplette epgsearch.log von heute würde ich gerne sehen

    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

    @nvertigo: Bosetti ist zwar ein Serientimer, aber AvoidRepeats steht auf No, dann wurde noch nie ein epgsearchdone.data-Eintrag erzeugt.

    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

    Like 1

    TomJoad :


    :thumbup:


    Code
    adler vdr # grep Elementary /etc/vdr/plugins/epgsearch/epgsearch.conf
84:Elementary:0:::2:frei:0:0:1:1:1:0:::1:0:0:1::50:99:5:10:0:0:0::1:0:1:1:0:0:0:0:0:1:0:0::1:0:0:0:0:0:0:0:0:0:90::0
adler vdr # grep "added rec done for .*Elementary" /etc/vdr/plugins/epgsearch/epgsearch.log
Di. 18.01.2022 15:00:00: added rec done for 'Elementary~Zwei Ohren zu viel';Elementary
adler vdr #

    Dankeschön! :)


    EDIT:

    Der Vollständigkeit halber: epgsearch schlägt bei der Wiederholng von "Zwei Ohren zu viel" nicht mehr an.

    Bei mir liefen seit gestern mit dem Patch -v3 auch einige Suchtimer. Diese wurden soweit ohne Auffälligkeiten und Abstürze durchgeführt.

    Ich werde das die nächsten Tage weiter beobachten.


    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

    Like 1

    TomJoad ,


    nachdem ich epgsearch mit Patch -v3 einige Zeit beobachtet habe, kann ich bestätigen, das es damit prinzipiell funktioniert.


    Allerdings konnte ich eine Abweichung zum alten Stand feststellen:

    Wenn man bei einem bereits laufenden Suchtimer die Endezeit vorzieht, wird dieser Timer nicht mehr als erledigt markiert. Das hat bisher funktioniert.

    Hintergrund dazu:

    Wenn man Timer-Konflikte hat und das erst feststellt, wenn eine dazu gehörende Aufnahme bereits läuft, kann man das durchaus bereinigen, indem man die Endezeit der laufenden Aufnahme und die Anfangszeit folgender Aufnahmen ändert. Das Ganze natürlich im Rahmen der Vor- und Nachlaufzeiten, so das davon ausgegangen werden kann, das eine erledigte Aufnahme zeitlich in Ordnung ist.

    epgsearch müsste also seine zwischengespeicherten Timer auch anpassen, wenn ein laufender Suchtimer geändert wird.


    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

    Das Problem von kamel5 lässt sich ohne Änderung im main-vdr nicht lösen. Bei Timeränderungen werden keine timerchange-Statusmeldungen verschickt.

    Das Behandeln des Aufnahmeendes musste mit 2.4 wegen der Lockgeschichten in einen extra-Thread verlegt werden. Damit konnte auch vor 2.5 nicht wirklich gewährleistet werden, dass das zugehörige Timerobjekt noch vorhanden ist.

    Bei manuellem Eingriff muss man wohl auch selber dafür sorgen, dass die Aufnahme als erledigt gekennzeichnet wird.

    Ich habe die Änderungen hochgeladen. Zusätzlich gibt es eine neue Konfigurationsvariable unter Suchtimer: "Erlaubte Fehler" (default: 0). Hat in 2.6 eine Aufnahme mehr als die erlaubten Fehler, wird sie nicht als erledigt eingetragen.

    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

    Like 5

    Kleiner Typo beim Service:


    Code
    msgid "This version of EPGSearch does not support this service!"
-msgstr ""
+msgstr "Diese Version unterstützt diesen service nicht!"

    Gruß utiltiy



    VDR Projects

    Hi TomJoad und ihr Wissenden ....
    Ich bin gerade auf der Suche, warum seit ich von der reelbox auf den NUC/BM2LTS umgestiegen bin, die epgsearchdone.data nicht mehr aktualisiert wurde....

    vdr: [1794] epgsearch: finished: '/media/hd/recordings/WELT_Newsroom/2024.01.27-14:30-Sa/2024-01-27.14.15.21-0.rec' but 2 errors); search timer: 'WELT Newsroom'; VPS used: No [/tt]

    vdr: [1794] EPGSearch: recdone thread ended (pid=1362, tid=1794) [/tt]


    Dadurch dass das mcli plugin (Netceiver Empfang) und der aktuelle vdr nicht immer perfekt harmonieren, hat fast jede Aunahme ein paar Fehler. Das fällt beim Schauen auch nicht ins Gewicht...


    Kann man dieses Verhalten (wenn Fehler >0 keine Eintrag in epgsearchdone.data) konfigurieren = Ev. Fehlernanzahl toleranter od. einfach abschalten ?

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Edited 2 times, last by gggggg ().

    kfb77 Hast du ev. eine Idee / Erklärung ?


    Aktuell bin ich überhaupt verwirrt, weil er schreibt auch dann nicht wenn 0 Fehler sind

    setup.conf:

    2 Woran kann es zus. noch liegen. Ich habe den Suchtime angelegt, da lief die Sendung bereits und zus. hab ich das Ende mit einer negativen Nachaufzeit von -10 eingestellt, damit die Testaufnahme kürzer ist ...

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Edited once, last by gggggg ().

    kfb77 Danke ... DAU am Werk ;) ....

    - Bezieht sich vollst. auf ohne Berücksichtigung der Vor-/Nachlaufzeiten ?

    - Muss der Errorcount der Aufnahme tats.=0 sein, weil das krieg ich selten hin (siehe mein Post 2 Posts oberhalb)

    Liebe Grüße g ;)

    NCV6dvbS2+Alphacrypt+ORF, BM2LTS4.4 NUC11i3 NVMe+HDD, BM2LTS2.94.4 AVG1 T7400 SSD+HDD NvidiaGT720

    Edited once, last by gggggg ().

Participate now!

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

Register Yourself Login