[EPGSearch] Auswertung wenn Timer schon erstellt wurde

Ich verstehe es auch nicht, denn wie bei TomJoad verhält sich EPGsearch auch bei mir wie erwartet – allerdings ohne die Nutzung von EPG-Kategorien.

Was du vielleicht versuchen könntest, ist, das Plugin mit -P 'epgsearch -v 3' zu starten. Damit wird, wenn nicht miT -l eine andere Datei benannt wird, im Plugin-Konfigurationsverzeichnis ein Logfile angelegt. Dort finden sich vielleicht detailliertere Informationen über die Abläufe. Gegebenenfalls lassen sich zusätzliche auch auf die Schnelle in den Code einfügen. Wenn du selbst Hand anlegen möchtest, kannst du dir dein Tracking der Abläufe bei der Auswertung von EPG-Variablen in cSearchExt::MatchesExtEPGInfo() nach dem Aufruf von GetExtEPGValue() einbauen (oder auch in dieser Funktion).

Ach ja, vergewissere dich bitte auch, dass nicht eventuell eine Ausschlussliste hier zu unerwarteten Ergebnissen führt; siehe TomJoads Hinweis zu den Eigenheiten, fehlende Kategorien zu ignorieren. Ein entsprechendes Tracking müsstest du dann in cBacklist::MatchesExtEPGInfo() einfügen.

MegaV0lt , wenn ich Dich richtig verstehe hängt bei Dir der Name des Timers vom Inhalt der Description des Events ab. Wenn jetzt erst der Timer angelegt wird und sich danach die Description des Events ändert, dann müsste sich auch der Name Timer ändern. Was er aber nicht tut.

Habe ich den von Dir gemeldeten Fehler richtig beschrieben?

Ich habe nochmals kurz im Code nachgeschlagen: Die Meldung "already created by search id … - won't be touched" rührt daher, dass die ID des Suchtimers, der einen bestehenden Timer ändern möchte, nicht mir der in den Aux-Daten des Timers gespeicherten "s-id" des ursprünglichen Suchtimers, der den betreffenden Timer seinerzeit angelegt hat, übereinstimmt.

Hast du eventuell zwei Suchtimer laufen, von denen jeder Ergebnisse für die gleiche Sendung liefert?

Wenn man die VDR-Timer mit:

svdrpsend lstt| grep "Chicago Fire"

…auflistet, bekommt man am Ende eines jeden Timers die Aux-Daten, wobei die Daten von EPGsearch von <epgsearch>...</epgsearch> umschlossen sind. Ein (in Teilen konstruiertes) Beispiel:

250-129 1:30:2025-12-08:0540:0655:30:14:Chicago Fire~Schatzkiste:<epgsearch><channel>30 - VOXup</channel><searchtimer>Leverag</searchtimer><start>1765168800</start><stop>1765173300</stop><s-id>192</s-id><eventid>39283</eventid></epgsearch>

Nun kann man mit der Nummer innerhalb von <s-id>...</s-id> den Suchtimer abfragen:

[BASH 2004] svdrpsend plug epgsearch lsts 192
220 HTPC SVDRP VideoDiskRecorder 2.7.7; Sun Dec  7 16:44:17 2025; UTF-8900 192:Chicago Fire:0:::2:RTL-Gruppe:0:3:1:0:0:0:::1:0:0:1::30:14:10:20:0:0:0::1:0:1:2:0:0:0:0:0:0:0:3::1:0:0:0:0:0:0:0:0:0:0::0:0:0:0:0:18
221 HTPC closing connection

Den VDR-Timer findet EPGsearch per Vergleich von Kanalnummer sowie (mit etwas erlaubter Unschärfe) von Start- und Stoppzeit. Wenn dabei ein Timer mit einer s-id gefunden wird, die von der ID des im Suchtimer-Thread überprüften Suchtimers abweicht, kommt diese Log-Meldung.

Wenn du selbst baust, dann füge doch bitte diesen Patch in EPGsearch ein:

diff --git a/searchtimer_thread.c b/searchtimer_thread.c
index b8aca57..151c53e 100644
--- a/searchtimer_thread.c
+++ b/searchtimer_thread.c
@@ -385,7 +385,7 @@ void cSearchTimerThread::Action(void)
                             continue;
                         }
                         if (triggerID > -1 && triggerID != searchExt->ID) {
-                            LogFile.Log(2, "timer for '%s~%s' (%s - %s, channel %d) already created by search id %d - won't be touched", pEvent->Title() ? pEvent->Title() : "no title", pEvent->ShortText() ? pEvent->ShortText() : "no subtitle", GETDATESTRING(pEvent), GETTIMESTRING(pEvent), ChannelNrFromEvent(pEvent), triggerID);
+                            LogFile.Log(2, "ID %d: timer for '%s~%s' (%s - %s, channel %d) already created by search id %d - won't be touched", searchExt->ID, pEvent->Title() ? pEvent->Title() : "no title", pEvent->ShortText() ? pEvent->ShortText() : "no subtitle", GETDATESTRING(pEvent), GETTIMESTRING(pEvent), ChannelNrFromEvent(pEvent), triggerID);
                             delete timer;
                             continue;
                         }

Damit wird im Log sowohl der überprüfte Suchtimer ("ID …" ) ausgegeben als auch der Suchtimer ("search id …"), der den VDR-Timer angelegt hat. Wenn sich die beiden Werte unterscheiden, hast du zwei unterschiedliche Suchtimer, die zur selben Sendung einen Timer setzen wollen. Falls sie identisch sind, müssen wir weitersuchen.

Quote from MegaV0lt

Keine Anzeichen für einen Timer, der da dazwischen funkt

Diese Filter hilft uns bei deinem Problem leider nicht weiter, weil er nicht die in Frage kommenden Suchtimer als potentielle Quellen für den Konflikt bei den VDR-Timern liefert.

Bin mir nicht sicher, ob die Fährte wirklich falsch ist. Klar ist, dass jeder VDR-Timer nur mit einem Suchtimer verknüpft sein kann. Wenn du also zwei Suchtimer hast, die einen Timer für die gleiche Sendung (Kanal, Start- und Stoppzeit) setzen bzw. ändern wollen, wird nur der ursprüngliche Suchtimer eine Änderung durchführen können. Wenn also dein Suchtimer "Empfehlenswert" ein Double liefert, haben wir genau den Fall.

Quote from MegaV0lt

Aber wenn wie oben found 0 events kommt, müssten die 'alten' Timer doch entfernt werden?

Nein, das macht EPGsearch nicht. Wenn für einen Suchtimer keine Events gefunden werden, werden auch keine Timer bearbeitet, also bestehende auch nicht gelöscht. Die alten Timer bleiben unverändert, was eventuell eine Vorsichtsmaßnahme ist, sich gegen Störungen in der EPG-Übermittlung abzusichern.

Wenn man erzeugte Suchtimer löschen will, muss man das meines Wissen explizit über "Aktionen" im Suchtimer-Menü des OSD machen (Punkt 10):

Eine andere Möglichkeit ist mir nicht bekannt. Nur wenn man im OSD einen Suchtimer deaktiviert oder löscht, wird man gefragt, ob man die zugehörigen Timer auch deaktivieren bzw. löschen möchte.

Wende bitte den Patch an und beobachte das Log. Deine Argumente scheinen sich für mich im Kreis zu drehen, und so kommen wir nach meinem Dafürhalten nicht weiter. Wir brauchen Daten aus deinem Environment, weil ich das bei mir nicht reproduzieren konnte.

Quote from MegaV0lt

In dem Fall müsste aber trotzdem geprüft werden, ob sich die EPG-Felder geändert haben. Wird es ja intern offensichtlich, da keine Events gefunden werden. Warum sollte dann ein Von dieser Suche erstellte Timer nicht gelöscht werden? Die s-id wird ja gespeichert, und ist ja dann auch eindeutig dem Timer zuweisbar.

Wie gesagt: Die Meldung besagt, dass EPGsearch im EPG keine passenden Sendungen gefunden hat, weshalb es keine auch weiteren Aktionen unternommen hat.

Ich würde es nur ungern sehen, wenn EPGsearch bereits erstellte Timer löscht und Aufnahmen damit entfallen, nur weil das EPG gerade ein wenig "herumzickt". Lieber finde ich in der Aufzeichnung (bspw. wegen einer aktuellen Programmänderung) etwas Anderes als das Erwartete, als dass eine Aufnahme fälschlicherweise (bspw. wegen zeitweise nicht vorhandener EPG-Daten) nicht durchgeführt wird. Allerdings kann man sich in solchen Situationen nicht 100-prozentig auf die automatische Vermeidung von Wiederholungen verlassen, weshalb ich diese auch nicht nutze.

Puh, der Code ist echt kompliziert. Da muss ich nochmals nachsehen…

Aber die Frage, welche Konflikte bei der Modifikation von Timern auftreten, ist damit noch immer nicht geklärt. Leider habe ich noch keine Antwort von dir erhalten, ob du den Patch appliziert hast und welche Log-Einträge daraus resultieren.

Ich hatte am 3. 12. geschrieben, dass nicht mehr passende Timer gelöscht werden, wenn epgsearch das aus den Eintragungen im Timer erkennen kann. Wenn nicht unbekannte Randbedingungen auftreten, bleibe ich dabei.