VDR Developer Version 2.5.1 - "Pattern Timer"

Zitat von jsffm

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:

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

Bei mir sind es 48 ;-).

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

jsffm Kannst zum Thema "Pattern Timer spawnt nicht sofort nach Änderung" bzw. "...nach beendeter Aufnahme" bitte mal das hier testen:

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

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.

Wie sehen die denn aus?

Edit: Hab's gesehen- "Leute heute" entsteht sehr oft...

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