Posts by TomJoad

Danke erstmals, ich habe keine Einwände gegen die Verbesserungen und werde sie ins git einpflegen

Das war schon immer so, wenn "TimerProgRepeat" eingeschaltet ist. Die Standardeinstellung für "Timer nach Löschen neu programmieren" ist aber "nein".

Man kann halt den Suchbegriff auf "Sportschau" im Titel und Kanal, Wochentag und Zeit einschränken, ausführlicher sollte man die Suche nur machen, wenn unbedingt nötig. Auf der anderen Seite will epgsearch sich dagegen absichern, dass ein Event ausfällt oder durch einen ganz anderen ersetzt wird. Da zu entscheiden, ob es doch das gewünschte ist, ist dann nicht mehr möglich.

Der Timer aus der VDR-Timerliste enthält zumindest in diesem Spezialfall die gleichen Zeiten, die die ursprüngliche Suche erzeugt hat (mit entsprechden Margins) , aber das Event aus dem Timer enthält einen Titel der nicht mehr zur timersdone.conf passt. Es verbessert auf jeden Fall die Möglichkeit, einen Match zu finden. Bei mir ist einige Stunden später wieder der ursprüngliche Timer erzeugt worden und genauso wie vorher in die timersdone.conf eingetragen.

Der folgende Patch behebt das vorliegende Problem:

--- a/timerdone.c	2021-04-03 12:10:22.462076530 +0200
+++ b/timerdone.c	2025-03-19 19:32:54.985101848 +0100
@@ -50,8 +50,9 @@ cTimerDone::cTimerDone(const time_t Star
 bool cTimerDone::operator== (const cTimerDone &arg) const
 {
     if (start == arg.start && stop == arg.stop && channelID == arg.channelID) {
-        if (title != arg.title) return false;
-        if (shorttext != "" && arg.shorttext != "" && shorttext != arg.shorttext) return false;
+// the following will not match if EPG-event has changed! 
+//      if (title != arg.title) return false;
+//      if (shorttext != "" && arg.shorttext != "" && shorttext != arg.shorttext) return false;
 
         if (searchID > -1 && arg.searchID > -1)
             return searchID == arg.searchID;
--- a/searchtimer_thread.c	2025-03-19 18:59:53.489953770 +0100
+++ b/searchtimer_thread.c	2025-03-19 19:02:20.379210245 +0100
@@ -765,8 +768,10 @@ void cSearchTimerThread::RemoveTimer(con
     if (EPGSearchConfig.sendMailOnSearchtimers)
         mailNotifier.AddRemoveTimerNotification(t, e);
     if (!EPGSearchConfig.TimerProgRepeat) {
-        cTimerDone * TimerDone = TimersDone.InList(t->StartTime(), t->StopTime(), e, -1);
+        cSearchExt* trigger = TriggeredFromSearchTimer(t);
+        cTimerDone * TimerDone = TimersDone.InList(t->StartTime(), t->StopTime(), e, trigger->ID);
         if (TimerDone) {
+            LogFile.Log(3, "Remove Timer from timersdone.conf");
             cMutexLock TimersDoneLock(&TimersDone);
             TimersDone.Del(TimerDone);
             TimersDone.Save();

Ich hab das ganze jetzt nachvollziehen können:

Nachdem erstmal 3 Timer für "Sportschau Bundesliga am Sonntag" angelegt wurden, werden heute nur noch 2 Timer gefunden

der Event heisst jetzt plötzlich

E 7891 1743968700 1800 54 6
T Sportschau
statt T Sportschau Bundesliga am Sonntag

Das Problem ist, dass nun zwar der Timer mit der richtigen Id aus der timers.conf gelöscht wird, aber für das Löschen aus der timersdone.conf der Titel vom aktuellen Event hergenommen wird und dann dort nicht gefunden wird. Dadurch bleibt der Eintrag erhalten, und es wird auch dann kein neuer Timer erzeugt, wenn im EPG wieder der ursprüngliche Titel auftaucht.

Insofern würde der obige patch, der den Titel beim Vergleich rausnimmt, helfen. Leider würden dann evtl. aber Einträge von anderen Suchen mit der gleichen Start- und Stopzeit vorher gefunden, da in RemoveTimer() für den Vergleich die searchID nicht hergenommen wird. Ich denke über eine abwärtskompatible Lösung nach

Ich würde den Eintrag in timersdone.conf dann immer löschen, wenn epgsearch bei der aktuellen Suche keinen passenden Suchtimer findet. Unabhängig von TimerProgRepeat wird der Timer dann beim nänchsten Update wieder neu erzeugt, falls das EPG wieder funktioniert (hoffentlich rechtzeitig) und passt.

btw Einträge in timersdone.conf, die in der Vergangenheit liegen, werden immer gelöscht. Manuell gelöschte Timer werden von "outdated" nicht erfasst.

Ich kann das Löschen nur provozieren, dass ich dem Timer eine andere eventid unterschiebe. Falls kein Event gefunden wird, weil das EPG gerade nicht verfügbar ist, wird auch nicht gelöscht. Gibt es irgendwelche Unregelmäßigkeiten im EPG oder externes EPG?

Von meinem Verständnis ist dann in searchtimer_thread.c::RemoveTimer() die Abfrage von TimerProgRepeat falsch herumgesetzt (wenn kein Neuanlegen gewünscht ist, wird der Eintrag in timersdone.conf gelöscht). Hat jemand einen Einspruch, den Eintrag dann zu löschen, wenn TimerProgRepeat=1 ist?

Wenn epgsearch den Timer löscht, sollte in der epgsearch.log ein passender Eintrag "delete timer for ...." sein. Bitte Umgebung dieser Zeile posten!

Das ist eine Folge von "fix unnecessary redisplays" im vdr 2.7.4. Ein Workaround wird beim nächsten Update des Plugins im git sein.

Laut erstem Eintrag sollte es um den Timer für den 16.3. gehen und nicht um den 9.3. Ansonsten geht es um das normale OSD, live scheint diesen Teil nicht implementiert zu haben

Die epgsearch.log sollte erkennen lassen, was epgsearch zu den passenden Zeitpunkten tut. Was das Skript epgsearch_mkrecording_user macht, kann ich nicht beurteilen. Wenn der Eintrag in der timersdone erscheint, wird der Timer i.d.R. nicht nochmal erzeugt. Im dem Menü, wo Suchen erzeugt und bearbeitet werden, kann man zum betreffenden Suchtimer in den Aktionen sich die erzeugten Timer auflisten lassen. Wenn man dort einen erzeugten Timer löscht, wird er aus der timersdone.conf entfernt und sollte beim nächsten Suchtimer-Update wieder erzeugt werden.

Muss ich ausprobieren. Das ist alter Code und muss veranlasst worden sein, weil im ersten Schleifendurchlauf oder durch später gestartete Plugins doch noch was passieren kann.

Für die DEPRECATED-Warnung weiss ich auch keine Lösung, aber bisher hat epgsearch den allerersten Aufruf vom MainThreadHook() benutzt, die Variable VDR_readyafterStartup zu setzen. Dadurch war sichergestellt, dass vdr mit dem startup komplett durch ist und der Suchtimerthread beginnen konnte. Ich suche im Augenblick eine andere elegante Lösung.

Gibt aber dann keine andere Erklärung als dass es mit der Search-ID und der Startzeit in der timersdone.conf stand

Hast Du mal in der epgsearch.log geschaut, ob es Hinweise gibt?

cPlugin::Housekeeping() wird bei mir nur nach Inactivity-Timeout aufgerufen, sonst nie (auch nicht beim normalen Runterfahren nach HITK Power).

cPlugin::Ready() würde für epgsearch und m.E. auch für alle softhddevice-Varianten reichen (bis auf X11-Ready), weil nur auf den ersten Aufruf von MainThreadHook() gewartet wird. Bei epgsearch, um sicher zu sein, dass vdr READY ist und svdrpsend funktioniert. Ich hatte schon eine konfigurierbare Zeitverzögerung eingebaut, damit nicht gleich der erste Suchtimer-Thread losläuft, aber diese Zeit nach dem Plugin::Start() laufen zu lassen, gefällt mir weniger.

Ich habe aber eine Reihe Plugins gefunden, die duch MainThreadHook() jede Sekunde eine Statusüberprüfung machen (dbus2vdr, restfulapi, web, graphtftng,...) . Dafür einen eigenen Thread laufen zu lassen, der immer wieder eine Sekunde schläft, ist auf jeden Fall Aufwand.

Bei mir funktioniert das alles mit VPS und epgsearch ohne Klimmzüge, es wird ein Timer auf den 1.Event gesetzt und es werden 2 Aufnahmen erzeugt, eine von der 1.Halbzeit mit ganzem Vorlauf und eine von der 2.Halbzeit mit ganzem Nachlauf.

vdr 2.6.9 ohne Änderungen im Timer-Komplex

Wenn man mit vdr einen Timer für die erste Halbzeit mit VPS=ja erzeugt, werden beide Halbzeiten in der Programmübersicht mit T bzw. TV markiert, weil sie die gleiche VPS-Zeit haben. Das hat bei mir auch immer zum Aufnehmen funktioniert. Ich nehme an, dass die Voreinstellung für VPS bei dir eine Rolle spielt.

Der Patch von kfb77 ist seit Jan 2023 in epgsearch (Version 2.4.2)