Den Patch fände ich gut, damit könnte ich zweigleisig fahren, mal mit, mal ohne VPS.
VDR Developer Version 2.5.1 - "Pattern Timer"
-
-
Jetzt interessiert mich noch, welchen Einfluss es auf "normale" Timer, also ohne VPS, hat, wenn ich im Aunahmemenü VPS aktiviere.
Setup.UseVps hat keinen Einfluss auch "normale" Timer.
MANUAL:
CodeUse VPS = 0 Defines whether a timer that is created from an EPG entry (by pressing the "Record" (red) key in the "Schedules" or "What's on now/next?" menu) will automatically use VPS if the event it is created for has a VPS time.
Es wirkt sich also ausschließlich beim Anlegen eines Timers aus dem Menü heraus aus.
Der oben angegebene Patch ist notwendig, damit auch bei Setup.UseVps=false alles wie gewünscht funktioniert.
Danke für den Bug-Report!
-
Danke für die Erläuterung, hätte ich auch finden können/sollen
Nebenbei, ich habe mittlerweile 28 Patterntimer angelegt, die einwandfrei funktionieren! Danke für dieses Feature,
-
Bei mir sind es 48 ;-).
-
Leider muss ich noch ein Problem melden:
Auf einem anderen vdr folgende Programmierung: Eine Serie ohne @ angelegt, da ich auch die Nachtwiederholung aufgezeichnet werden soll. Zwischen Nachtwiederholung und nächster Folge keine weitere Programmierung. Nach der Nachtwiederholung fährt der Rechner runter bevor der nächste Timer angelegt wird, dass kann ich im Protokoll nachvollziehen. So wird die mächste Folge verpasst.
-
Das könnte dann erledigt sein, wenn Pattern Timer auch direkt auf Veränderungen der Timer-Liste reagieren. Momentan ist es so, dass ein Pattern Timer nur dann "spawnt", wenn sich die EPG-Daten des betreffenden Kanals ändern. Ich werde das noch so machen, dass das auch bei jeder Änderung der Timer-Liste passiert (das Beenden eines Timers verursacht ja auch eine solche Änderung).
Behalte diesen Fall bitte im Auge und verifiziere es mit der nächsten Version von VDR (ich bin momentan an einer anderen Ecke tätig, daher wird es noch ein paar Tage dauern damit).
-
Aufgrund der EPG-Änderungen auf "Das Erste" heute Abend verschiebt sich extra 3, VPS würde das erledigen, ohne habe ich jetzt 2 Einträge, den Alten und den Verschobenen, der Alte müsste dann gelöscht werden.
-
jsffm Kannst zum Thema "Pattern Timer spawnt nicht sofort nach Änderung" bzw. "...nach beendeter Aufnahme" bitte mal das hier testen:
Diff
Alles anzeigen--- epg.c 2021/01/04 09:05:26 5.1 +++ epg.c 2021/01/08 10:12:19 @@ -920,6 +920,7 @@ { numTimersMutex.Lock(); numTimers++; + modified++; numTimersMutex.Unlock(); } @@ -927,6 +928,7 @@ { numTimersMutex.Lock(); numTimers--; + modified++; numTimersMutex.Unlock(); } --- epg.h 2017/05/28 12:59:20 5.0 +++ epg.h 2021/01/08 10:12:41 @@ -156,7 +156,7 @@ cHash<cEvent> eventsHashStartTime; mutable u_int16_t numTimers;// The number of timers that use this schedule bool hasRunning; - int modified; + mutable int modified; time_t presentSeen; public: cSchedule(tChannelID ChannelID);
-
Danke, werde ich auf meinem Testsystem, wo das Problem auftrat, einbauen.
-
Ist eingebaut, die gleiche Konstellation wird verm. in der Nacht Mo-Di auftreten.
-
jsffm Kannst zum Thema "Pattern Timer spawnt nicht sofort nach Änderung" bzw. "...nach beendeter Aufnahme" bitte mal das hier testen:
Diff
Alles anzeigen--- epg.c 2021/01/04 09:05:26 5.1 +++ epg.c 2021/01/08 10:12:19 @@ -920,6 +920,7 @@ { numTimersMutex.Lock(); numTimers++; + modified++; numTimersMutex.Unlock(); } @@ -927,6 +928,7 @@ { numTimersMutex.Lock(); numTimers--; + modified++; numTimersMutex.Unlock(); } --- epg.h 2017/05/28 12:59:20 5.0 +++ epg.h 2021/01/08 10:12:41 @@ -156,7 +156,7 @@ cHash<cEvent> eventsHashStartTime; mutable u_int16_t numTimers;// The number of timers that use this schedule bool hasRunning; - int modified; + mutable int modified; time_t presentSeen; public: cSchedule(tChannelID ChannelID);
Hat funktioniert, jetzt hat er den Timer angelegt, bevor er runterfährt. Damit wird der Wakup korrekt gesetzt.
-
Es wäre nicht schlecht, wenn bei Aufnahmestart der EPG auf Verschiebung überprüft wird und gegebenenfalls der Timer korrigiert wird.
-
Die Änderung von #68 dürfte zwar gut wirken, schlägt aber viel zu oft (unnötig) zu.
Ich werde es daher so lösen wie im beiliegenden Patch (anstatt dem in #68).
Bitte nochmal testen.
-
Auf Testsystem eingespielt, werde das im Auge behalten.
-
-
Wie sehen die denn aus?
Edit: Hab's gesehen- "Leute heute" entsteht sehr oft...
-
-
Sind doch noch mehr da, die ich deaktiviert habe:
Codevdr3-2 vdr-2.5.1 # svdrpsend lstt | grep "Deutschland von oben" 250-158 0:47:MTWTFSS:0000:2359:50:99:{Deutschland von oben}TITLE: 250-161 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben: 250-162 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben: 250-167 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben: 250-168 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben: 250-170 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben: 250-171 17:47:2021-01-22:0440:0510:50:99:Deutschland von oben: 250 172 16:47:2021-01-22:0440:0510:50:99:Deutschland von oben:
-
Hab's nachvollziehen können und gehe dem gleich nach.
-
Das Problem hier ist, dass der eigentlich aufzunehmende Event sehr kurz ist (5 Minuten) und der Timer mit seinen 10 Minuten Nachlaufzeit auch den nachfolgenden Event (der 10 Minuten dauert) vollständig überlappt. In cTimer::SetEventFromSchedule() greift daher die Bedingung "if overlap is the same, we take the longer event"; beide Events werden zu 100% überlappt, und der zweite ist der Längere.
Damit wird dem Timer der zweite Event zugewiesen, und der erste hat keinen Timer mehr. cTimer::SpawnPatternTimers() erzeugt daher einen neuen Timer und das Spiel beginnt von vorne. Mit VPS könnte man das zwar auf diesem Kanal umgehen, aber das ist keine allgemeine Lösung.
Im konkreten Fall hilft erstmal, die Timer-Nachlaufzeit auf unter 10 Minuten zu verkürzen.
Um das Problem allgemein für Aufnahmen ohne VPS in den Griff zu bekommen werde ich wohl dafür sorgen müssen, dass die Vor- und Nachlaufzeit des Timers immer klein genug ist, damit weder der vorherige noch der nachfolgende Event zu 100% überlappt wird.
Als "Notbremse" könnte in cTimer::SpawnPatternTimers() auch noch geprüft werden, ob es bereits einen "gespawnten" Timer mit diesen Einstellungen gibt - falls es noch aus irgendwelchen anderen Gründen aus dem Ruder laufen sollte...
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!