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?
Vllt. im Konflikt mit Pattern Timer, einer neuen Funktion seit 2.5.x?
@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.
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
bei mir sieht das so aus. Aufnahme war i.O.
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 finishedHä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:
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 endedGrüße
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.
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.
Danke für Deine Arbeit! Eine Frage: auf welchen git Stand muss Dein Patch angewendet werden? Bei https://projects.vdr-developer…84af3da9e57f9074df79b2db0 funktioniert es jedenfalls nicht.
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... 
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!