epgsearch erzeugt bei jedem Durchlauf zusätzlichen Timer für eine Sendung

Hi,

Hast du Wiederholung vermeiden an?

Mfg Stefan

Das tritt bei mir auch zwei mal im Jahr aus bei der Zeitumstellung

Zitat von maf

Als ein Problem, dass sich vielleicht ab 2022 nicht mehr stellt

Ein Optimist!

Ich glaube nicht dran...

Ich habe es eben probiert und konnte es nicht reproduzieren (Desperate Measures auf dem ZDF).

Die Entsprechenden Einträge in der 'timers.conf', epg.data, epgsearchdone.data wären hilfreich, wenn du die rein stellen könntest.

Dann müsste man nachvollziehen können, warum epgsearch die selbst programmierten Timer ignoriert.

Auf jeden Fall sind in 2.4 im VDR Patches reingekommen. Es hatte in epgsearch Probleme gegeben, weil die Dauer der Sendung im VDR falsch ermittelt wurde und nicht mit dem EPG übereinstimmte. Das sollte alles behoben sein.

Ist im Zweifelsfall eh immer besser erstmal alles zu aktualisieren. VDR 2.2.0 ist auch alt...

Alle Jahre wieder. Wieder erstellt epgsearch massiv Timer in der Zeit wo umgestellt wird:

Kann ich nicht nachvollziehen. Bei mir erzeugt epgsearch mit Suchtimer "fear the walking" genau 5 Timer, auch nach weiteren Searchtimer-Updates bleibt es dabei.

Allerdings wird vdr wohl den 3. Timer von 2:03-2:00 von Sonntag 2:03 bis Montag 2:00 laufen lassen (so ist es im Schedule markiert) oder sofort beenden. In diesem Spezialfall könnte man es mit einem längeren Nachlauf wahrscheinlich korrigieren.

Es bleibt dabei, dass es kein Allheilrezept gibt und man in der Nacht immer aufpassen muss.

Ich habe das gleiche Verhalten wie MegaV0lt. Ich vermute, der Unterschied zu deinem Test kommt von "Timer nach Löschen neu erzeugen", den habe ich auf "Ja".

Beim Neustart vom VDR wird ein neuer Schwung Timer erzeugt. Die Einstellung neu erzeugen nach löschen hab ich auch an. Ich lösche aber die Timer nicht. Wenn dann deaktiviere ich die nur. Hab den Suchteimer bis morgen früh erst mal deaktiviert.

Nervt halt, weil das immer wieder passiert, wenn die Zeit umgestellt wird

Beim Timer von 2:03-2:00 liegt die Stop-Differenz vom geplanten und vorhandenen ca. 1 Tag auseinander, deshalb wird er neu erzeugt (nur, wenn Timer neu erzeugen gesetzt ist). Dieser Timer ist aber auch nicht sinnvoll und sollte nicht erzeugt werden (passiert aber auch ohne epgsearch)

Beim Timer von 2:43-3:45 liegt die Start-Differenz um 1 Stunde auseinander, das sollte eigentlich mal korrigiert worden sein.

Solange der vdr in der timers.conf nicht mit der Unixzeit arbeitet wie das EPG, sondern nur HH:MM des gewünschten Tages abspeichert, kann es während der Sommer-auf-Winterzeit-Umstellung Probleme geben. Hier sind die Zeiten am Sonntag zwischen 2:00 und 2:59 zweideutig. Die Anfangszeit kann eine Stunde zu früh liegen und die Endezeit kann vor der Anfangszeit liegen bei Sendungen, die aktiv sind um 3:00.

(mktime wird bei der Rückumwandlung aus Datum-Uhrzeit in Unixzeit in diesem Zeitraum immer die Sommerzeit hernehmen)

Daran kann epgsearch nichts ändern. Epgsearch müsste bei der Überprüfung, ob ein Suchtimer für ein Event schon existiert (bei Erzeugen nach Löschen auf ja), die gleichen Zwischenschritte machen (Event->tm, tm->Unixzeit).

Aber damit ist nicht gewährleistet, dass die erstellten Timer zu sinnvollen Aufnahmen führen. Hat mal jemand ausprobiert, ob der vdr vor der Aufnahme die Daten nochmal mit dem EPG abgleicht und korrigiert? Wenn ja, würde ich die Zwischenschritte einbauen.