[epgsearch] Time in timersdone.conf, aber es wurde keine Aufnahme eingestellt

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.

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

Quote from nobanzai

Nur dass der niemals aufgetaucht ist in der Timerliste.

Ab dem ersten skip timer for ... - already done ist der Timer nicht mehr da.

Es gab da eine Macke die zu dem beschriebenen Phänomen führt, wenn es einen kurzen EPG-Aussetzer gibt.
Arte EPG verhindert Suchtimeraufnahmen
(Die ersten 3 Absätze kannst Du ignorieren.)

Ich hatte mich damals auch an einem Patch versucht, den aber nie wirklich getestet.
(Ich verwende eigentlich schon immer "Timer nach löschen neuprogrammieren" "ja".)
Evtl. magst Du den mal versuchen?
Arte EPG verhindert Suchtimeraufnahmen

Irgendwie fehlte im EPGsearch-Log auch eine klare Meldung, wenn das Event verloren gegangen ist.
Wenn ich das recht erinnere war aber ein zweites added timer for ... für das gleiche Event ein ziemlich eindeutiges Abzeichen dafür.
Und dann schlug normalerweise auch der Bug zu, wenn "Timer nach löschen neuprogrammieren" auf "nein" steht.

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

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?

Quote from TomJoad

Hat jemand einen Einspruch, den Eintrag dann zu löschen, wenn TimerProgRepeat=1 ist?

Das verstehe ich nicht: Ist es nicht so, dass wenn TimerProgRepeat=1 die timersdone.conf ignoriert wird und auf jeden Fall ein neuer Timer erzeugt wird, wenn das Suchkriterium erfüllt ist ? Egal ob er zuvor gelöscht wurde oder noch nie da war.

Quote from TomJoad

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).

Das ist IMHO korrekt, so wie es ist.
Wenn TimerProgRepeat==1 ist wird die timers.done komplett ignoriert.

     // already done the same timer?
   if (!EPGSearchConfig.TimerProgRepeat && index == 0 && TimersDone.InList(start, stop, pEvent, -1)) {
       LogFile.Log(2, "skip timer for '%s~%s' (%s - %s); search timer: '%s' - already done", pEvent->Title(), pEvent->ShortText() ? pEvent->ShortText() : "", GETDATESTRING(pEvent), GETTIMESTRING(pEvent), searchExt->search);
       return false;
   }

Quote from TomJoad

Hat jemand einen Einspruch, den Eintrag dann zu löschen, wenn TimerProgRepeat=1 ist?

Wenn ich nicht irre, würde das dazu führen, dass Einträge in der timers.done beim löschen eines Timers durch das Plugin nie gelöscht würden.

Irgendwie ist diese Abfrage aber schon sinnlos (bei TimerProgRepeat==1 ist wird die timers.done ja ignoriert), aber man sollte den Eintrag in der timers.done immer löschen.

TimerProgRepeat==0 soll IMHO ja nur das erneute programmieren eines Timers unterbinden, wenn der Benutzer ihn (absichtlich) löscht.

Ich konnte damals das Problem darauf einkreisen, dass der timer nicht aus der timers.done gelöscht wurde.
Mein Versuch das zu beheben war der Patch aus Beitrag #6.

Quote from TomJoad

Gibt es irgendwelche Unregelmäßigkeiten im EPG oder externes EPG?

Bei den ARD-Kanälen hatte ich das damals bei meinen Tests dauernd.
Die Senden das EPG für alle Sender auf x Transpondern und bekommen das anscheinend manchmal nicht hin das alles aktuell und synchron zu halten.
Das trat nicht immer auf, aber gerne mal bei dem großen, täglichen Update um 6:00.
Ob man es bei EPGsearch überhaupt merkt, scheint auch von channels.conf und der Anzahl der DVB-Karten und deren Auslastung abzuhängen.

Da das Ganze diese blöde Timing-Komponente hatte und die Fehler nur sporadisch und zu den unmöglichsten Zeiten auftraten, hab ich es dann irgendwann aufgegeben den Verursacher zu suchen.
Ich habe dann kurzerhand den EPG von Fremdtranspondern komplett abgeklemmt, seit dem ist Ruhe: Arte EPG verhindert Suchtimeraufnahmen.

Wenn die Fehler seit Anfang den Jahres vermehrt auftreten, würde ich auf die abgeschalteten SD-Transponder als Quelle tippen.
Auch wenn auf den Kanälen nichts mehr kommt, heisst das lange nicht, dass die da auch kein EPG mehr senden. Wirklich pflegen wird die Transponder/Daten da aber wohl niemand mehr.

edit:
Wer will könnte auch mal den diesen Patch von kls testen, vielleicht behebt der die EPG-Probleme auch schon. So wie ich es eben sehe, hat der es doch nicht in den VDR geschafft.: Arte EPG verhindert Suchtimeraufnahmen
Bei meiner alten VDR-Version passte das damals schon nicht gut, deshalb hatte ich da einen etwas "radikaleren" Ansatz gewählt. Der was nicht so gut angekommen .

Die Zeilennummern haben sich zwar etwas geändert, aber generell sollte es noch passen.
Eigentlich sind auch lediglich 2 Zeichen in eit.c zu ändern:
In Zeile 497 das "0xC0" in "0xE0" und in Zeile 524 das "0x6F" in "0x5F".

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 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

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();

Quote from TomJoad

ch 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.

Macht für mich Sinn.
Ich denke, das war auch gedacht so.

Quote from TomJoad

der Event heisst jetzt plötzlich

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

Eine einfache Änderung in (Sub-)Title sollte EPGsearch eigentlich verkraften.

Dann ist diesmal jedenfalls eindeutig der Sender selber die Ursache.
Bei der Arte-Geschichte war das ja nicht wirklich eindeutig raus zu finden, was da los war.

Quote from TomJoad

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.

Das hatte ich damals wohl nicht gesehen.

Wobei, wo ich den Patch anschaue, fällt mir gerade auf, dass die Zeiten vom Timer genommen werden und das Event aus dem EPG.
Würde es einem Unterschied machen, das Event aus dem Timer zu verwenden?

cTimerDone * TimerDone = TimersDone.InList(t->StartTime(), t->StopTime(), t->Event(), trigger->ID);

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.

Quote from TomJoad

aber das Event aus dem Timer enthält einen Titel der nicht mehr zur timersdone.conf passt.

Irgendwie hatte ich das befürchtet.
Das wird dann wohl ein Link auf das aktuelle Event sein.

Egal, die Lösung mit der TimerId sollte auch eindeutig sein und das Problem beheben.

Quote from TomJoad

Bei mir ist einige Stunden später wieder der ursprüngliche Timer erzeugt worden und genauso wie vorher in die timersdone.conf eingetragen.

Jetzt ist bei mir auch wieder "Bundesliga" um Untertitel, zwischenzeitlich war der mal leer.
Wenn die den Suchbegriff im letzten Moment aus dem Event raus nehmen wird man aber nicht viel machen können .

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.