Interessant. OK, das würde natürlich für eine Vergrößerung des Buffers sprechen.
Posts by kls
-
-
In Zeile 121 heißt es, dass die CAT maximal 1024 Byte lang sein kann. Den Buffer zu vergrößern halte ich daher nicht für sinnvoll, da es ein eventuelles Problem wohl eher verschleiern würde.
Die Warnung fallls length > 1024 ist (da die Section-Length ja 12 Bit hat) wäre dagegen sicher sinnvoll.
MegaV0lt : magst du das mal testweise bei dir einbauen und versuchen, den Fall erneut zu forcieren?
-
Solange das nur ein einmaliges Ereignis war würde ich dem erstmal keine größere Bedeutung beimessen.
Sollte es wieder und reproduzierbar auftreten, melde dich bitte wieder.
-
Verschiebungen (ohne VPS) zu erkennen wird nochmal ein anderes Thema.
Das vorliegende Problem lässt sich aber wohl nur auf die angegebene Weise in den Griff bekommen.
Probier es bitte mal aus.
-
Mit folgender Änderung wird Vor- und Nachlaufzeit an die Länge des vorherigen bzw. nachfolgenden Events angepasst.
Damit klappt der konkrete Fall schon mal.
Display MoreDiff- --- timers.c 2021/01/15 13:52:40 5.4
- +++ timers.c 2021/01/18 20:48:43
- @@ -191,8 +191,22 @@
- time_t tstart = (flags & tfVps) ? Event->Vps() : Event->StartTime();
- time_t tstop = tstart + Event->Duration();
- if (!(HasFlags(tfVps))) {
- - tstop += Setup.MarginStop * 60;
- - tstart -= Setup.MarginStart * 60;
- + int MarginStart = Setup.MarginStart * 60;
- + int MarginStop = Setup.MarginStop * 60;
- + if (PatternTimer) {
- + // To make sure a spawned timer gets assigned to the correct event, we must
- + // make sure that this is the only event that overlaps 100%:
- + if (const cEvent *e = dynamic_cast<const cEvent *>(Event->Prev())) {
- + int d = e->Duration();
- + MarginStart = max(0, min(MarginStart, d - 60));
- + }
- + if (const cEvent *e = dynamic_cast<const cEvent *>(Event->Next())) {
- + int d = e->Duration();
- + MarginStop = max(0, min(MarginStop, d - 60));
- + }
- + }
- + tstart -= MarginStart;
- + tstop += MarginStop;
- }
- struct tm tm_r;
- struct tm *time = localtime_r(&tstart, &tm_r);
Vielleicht macht es sogar Sinn, das nicht nur auf Pattern-Timer zu beschränken.
Meinungen dazu?.
-
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...
-
Hab's nachvollziehen können und gehe dem gleich nach.
-
Wie sehen die denn aus?
Edit: Hab's gesehen- "Leute heute" entsteht sehr oft...
-
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.
-
jsffm Kannst zum Thema "Pattern Timer spawnt nicht sofort nach Änderung" bzw. "...nach beendeter Aufnahme" bitte mal das hier testen:
Display MoreDiff- --- 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);
-
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).
-
Bei mir sind es 48 ;-).
-
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:
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!
-
und damit verm. auch das VPS-Signal
VDR benutzt beim Timer-Anlegen nicht ein aktuell gesendetes "VPS-Signal", sondern den VPS-Eintrag des verwendeten Events.
-
Das ist natürlich aus, wenn ich das einschalte, welchen Einfluss hat das auf "normale" Timer, also ohne VPS?
Keinen. Das dient nur dazu, VPS beim Anlegen von Timern für Kanäle, die VPS senden, defaultmäßig einzuschalten.
Nach Aktivieren von VPS gleiches Ergebnis.
Hat der Pattern Timer den Timer auch wirklich *nach* dem Einschalten von Setup.UseVps neu angelegt?
Eventuell sollten wir diese Änderung machen:
Display MoreDiff- --- timers.c 2020/12/26 15:49:01 5.1
- +++ timers.c 2021/01/07 13:56:15
- @@ -183,7 +183,7 @@
- remote = NULL;
- event = NULL;
- if (!PatternTimer || PatternTimer->HasFlags(tfVps)) {
- - if (Event->Vps() && Setup.UseVps)
- + if (Event->Vps() && (PatternTimer || Setup.UseVps))
- SetFlags(tfVps);
- }
- LOCK_CHANNELS_READ;
denn so wie es momentan ist, klappen Pattern Timer mit VPS nur dann, wenn beim Spawnen auch Setup.UseVps eingeschaltet ist.
-
Ein "spawned" Timer mit VPS (und ohne "avoid") müsste 21 haben (tfActive + tfVps + tfSpawned).
Benutzt der Kanal T-8468-17922-833 denn überhaupt VPS?
Und hast du im Setup "Recording/Use VPS" eingeschaltet?
-
Ja, das sollte funktionieren. Ich habe etliche solcher Timer.
Woran scheitert es denn bei dir?
-
Ich denke mal, damit sollte es allgemein funktionieren (der obige Patch entfällt dann):
Display MoreDiff- --- epg.c 2019/05/20 09:55:22 5.0
- +++ epg.c 2021/01/04 09:05:26
- @@ -1311,8 +1311,13 @@
- fclose(f);
- if (result) {
- // Initialize the channels' schedule pointers, so that the first WhatsOn menu will come up faster:
- - for (cChannel *Channel = Channels->First(); Channel; Channel = Channels->Next(Channel))
- + for (cChannel *Channel = Channels->First(); Channel; Channel = Channels->Next(Channel)) {
- + if (const cSchedule *Schedule = Channel->schedule) {
- + if (!Schedule->ChannelID().Valid()) // this is the DummySchedule
- + Channel->schedule = NULL;
- + }
- Schedules->GetSchedule(Channel);
- + }
- }
- return result;
- }
-
Wobei mir einfällt, dass das nur für LSTE hilft.
Im Menü wird es dadurch noch nicht richtig angezeigt.
Da kommt noch ein anderer Patch.
-
Pattern Timer "spawnen" immer, wenn sich am EPG des jeweiligen Kanals etwas ändert (und sei es nur der Running Status).
Um bei unmittelbar aufeinander folgenden Treffern rechtzeitig die Aufnahem starten zu können, wird, falls ein Event matcht, auch der darauf folgende Event gecheckt und ggf. ein weiterer Timer angelegt.
Was ich noch machen muss ist, dass das auch bei jeder Änderung der Timer-Liste geschieht. Das ist momentan noch nicht der Fall, daher der Workaround mit dem löschen des EPG des Kanals.
