Posts by TomJoad
-
-
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:
Diff
Display More--- 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 SonntagDas 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?
-
-
-
-
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.
-
-
-
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)
-
Keine Aufrufoptionen, keine Veränderung des Setups. Interner Standard ist cOutputDvb. Das setzt softhddevice auf alsa um (bei mir ohne -a ...). Alles mit OSD und Ton. Grafik ist Intel-vaapi.