Topf schluckt Timer - woran liegt´s?

[chrisly]

Hi.

Im 3PG-Thread wurde schon hierüber diskutiert:

Gestern hat der Topf wieder nicht aufgenommen - immer bei der gleichen Sendung.

Von 17:53 Uhr bis 18:00 Uhr wird der Sandmann aufgenommen (klappt immer).
Um 18 Uhr soll dann die Explosiv-Aufnahme starten - klappt nicht immer, aber meistens.
Der Swat-Timer ist vorhanden, der Topf läuft schon wegen der Sandmann-Aufnahme und trotzdem nimmt der Topf Explosiv nicht immer auf (zum Glück betrifft es - bis jetzt - keine wirklich wichtigen Aufnahmen ... ).

FireBird hat mir daraufhin ein feines Tap zur Verfügung gestellt: TimerDiags (zeichnet alle "Timer-Bewegungen" auf). Und das hat jetzt gezeigt, dass der Fehler nicht bei 3PG liegt (deshalb dieser neue Thread).

Die Timer, die nicht ausgeführt wurden, sind demnach zum entspr. Zeitpunkt vorhanden, starten aber nicht. Dieses Problem tritt nur (aber zum Glück nicht immer) auf, wenn gerade eine Aufnahme zu Ende ging und zur gleichen Zeit eine neue Aufnahme starten soll.
Gestern z.B.: bis 17:53 Uhr = Momo
17:53 bis 18:00 Uhr sollte der Sandmann folgen, Aufnahme wurde aber nicht ausgeführt (dafür aber Explosiv um 18 Uhr - da war der Topf ja vorher auch wieder aus).

TimerDiags schrieb folgende Bewegungen in die Log:
Removed Timer (und Record): Momo (bis 17:53)
Removed Timer: Sandmann (17:53 - 18:00 Uhr) (in Log geschrieben um 18:00 Uhr)
Possibly missed Timer
Removed Timer: Explosiv (ab 18 Uhr) ...

Der Sandmann-Timer war also vorhanden. Warum wurde er nicht ausgeführt?
Den T-Patch habe ich drin. Das Problem tritt eigentlich erst seit ein paar Wochen auf (und nur bei Folgeaufnahmen, nachdem anderer Timer endete), vorher kam das nie vor.
Ich habe in letzter Zeit nichts an der FW geändert und keine neuen Taps aufgespielt - nur aktualisiert (AutoExtender, Overfly, filer, nicedisplay). Eigentlich müsste es ja damit zusammenhängen, weil es früher keine Probleme gab. Aber da es nur unregelmäßig vorkommt, ist ein entspr. Test auch schwierig.

Habt Ihr ´ne Idee???

[Töppi]

Den gleichen Test mal mit einer Standardfimrware ohne Patches ausführen.

[Julian]

Den gleichen Test mal mit einer Standardfimrware ohne Patches ausführen.

Der Vorschlag wird wem weh tun!!

[Töppi]

weiss ich, aber bei einer so extrem plattgepatchten Firmware kann man wirklich keine fundierte Aussage über irgendeinen Fehler machen. Auch wenns weh tut.

[chrisly]

Der Vorschlag wird wem weh tun!!

Stimmt!
Ich vermute, Töppi spielt damit auf den FW-Bug an, den ich ja dann bestätigen könnte.
Allerdings glaube ich kaum, dass es in meinem Fall damit zu tun hat, weil der Fehler ja bis vor ein paar Wochen gar nicht auftrat (und ich habe seit Monaten nichts mehr an der FW geändert - auch nicht neu gepatcht!).

[Töppi]

ich will nur sagen, dass sich auch im Topf/Settings/Senderlisten etwas verändern kann, der FP verschluckt sich, Patches haben Auswirkungen auf Funktionen usw.
Wenn du wirklich testen willst, bleibt dir meiner Meinung eben nur, den Topf bei 0 neu aufzusetzten, ohne Patches und TAPs. Die Konstellation ist doch an einem Tag gestestet, wenn du sagt, dass es nun täglich mit dieser Konstellation auftritt.

[chrisly]

Die Konstellation ist doch an einem Tag gestestet, wenn du sagt, dass es nun täglich mit dieser Konstellation auftritt.

Wenn´s so wäre, hätte ich es ja auch schon getestet. Aber leider tritt es nicht regelmäßig auf (nur gehäuft in den letzten Wochen). Und jetzt wochenlang mit "nackischem" Topf zu testen - das wäre für mich der Horror ...

[chrisly]

Vorgestern war´s wieder soweit - bei der gleichen Sendung.
Ich habe jetzt doch mal die zuletzt eingefügten Patches rausgeschmissen (das verkrafte ich gerade noch so ): Pc und Rp.

Vielleicht lässt es sich ja so eingrenzen ...

[goge]

Hi,
schau dir mal R2D2s Repeat Timer Patch an, evt schafft der Abhilfe.
Viele Grüße
goge

[chrisly]

Danke für den Tipp. Leider konnte ich den nirgendwo finden - nur den T-Patch.
Aber vom Namen her vermute ich, dass der nur was bei Wiederholungstimern bringt - oder?
Meine Timer werden alle per Swat angelegt.

[FireBird]

Aber vom Namen her vermute ich, dass der nur was bei Wiederholungstimern bringt - oder?

Yep. Der Topf hat ein paar Bugs in der Timerverwaltung und bei der Berechnung der nächsten Startzeit landen lange Wiederholungstimer manchmal nicht dort wo sie sollen.

[flechumer]

Hallo chrisly,
wirf mal versuchsweise AX raus.

[chrisly]

Hallo chrisly,
wirf mal versuchsweise AX raus.

Das hatte ich schon kurzzeitig, dann dachte (hoffte) ich aber, dass es eher an den Patches liegen könnte - auf die läßt sich leichter verzichten ...
Aber AX ist im Ernstfall der nächste Kandidat!
Ich habe in der AX-ini übrigens eingestellt, dass Sendungen erst ab 19 Uhr verlängert werden sollen. Die Probleme traten immer vor dieser Zeit auf.

@flechumer: Wie kommst Du auf diese Idee? Bis jetzt habe ich nirgends gelesen, dass AX solche Probleme auslösen könnte. Habe ich was übersehen?

[flechumer]

@flechumer: Wie kommst Du auf diese Idee? Bis jetzt habe ich nirgends gelesen, dass AX solche Probleme auslösen könnte. Habe ich was übersehen?

Weil AX prinzipiell in der Lage ist, Timer zu verkürzen oder auch ganz zu löschen. Das hängt aber von der Parametrisierung ab. Die einfachste Methode, das zu klären, ist halt, AX testweise nicht zu verwenden.

Ich habe in der AX-ini übrigens eingestellt, dass Sendungen erst ab 19 Uhr verlängert werden sollen. Die Probleme traten immer vor dieser Zeit auf.

Das legt nun aber die Vermutung nahe, daß es doch nichts mit AX zu tun hat. Für wiederkehrende Timer könntest Du auch den Parameter ProtectTimer einsetzen.

[chrisly]

Zwischenstand:
An den Patches lag es nicht.
Jetzt habe ich doch mal AX vorübergehend nicht mehr im Autostart. Mal sehen, was passiert ...
Für weitere Tipps bin ich natürlich immer noch dankbar!

[chrisly]

Hi flechumer.
Ich sag´s ja nur ungern - aber offensichtlich ist der Übeltäter doch Autoextender. Nachdem ich das Tap jetzt seit über 3 Wochen nicht im Autostart hatte, gingen die besagten Timer nicht mehr verloren. Kann zwar Zufall sein - aber mit AX (keine anderen Veränderungen) ging mind. 1x wöchentlich ein Timer verloren.
Komisch ist nur, dass ich in der AX-ini vorgegeben habe, dass AX erst ab 19 Uhr aktiv werden soll (ExtensionFrom = 19), die Timer aber zwischen 17 und 18 Uhr starten, also garnicht von AX angepackt werden. Allerdings habe ich für die betroffenen Timer aus früheren Zeiten auch noch zusätzlich ein "ExcludeEvent" definiert, also doppelt gemoppelt. Könnte das die Ursache sein?

[flechumer]

Die Uhrzeitbegrenzung der Wirkung von AX erstreckt sich nur auf die Verlängerungsfunktion und ist deshalb wahrscheinlich unerheblich. AX löscht Timer in genau zwei Fällen:

1. Etwa eine Min. vor Start eines Folge-Timers wird er gelöscht und gleichzeitig die laufende Aufnahme entsprechend verlängert - natürlich nur bei "AccTimers = ja".
2. Wird eine laufende Aufnahme durch die Verlängerungsfunktion von AX verlängert, so wird geprüft, ob dazu ein wartender Timer verschoben werden muß. Das kann dazu führen, daß der Timer letztlich ganz gelöscht wird. Die Verschiebung kann mit "MaxTimerDelay = ..." auf eine bestimmte Zeit begrent werden oder mit "ProtectTimer = ..." für eine bestimmte (auch wiederkehrende) Sendung ganz ausgeschlossen werden.

Andere Anlässe für Timer-Löschungen von AX gibt es nicht. Allerdings modifiziert AX Timer unter bestimmten Umständen: Verschieben des Starts, Umwandlung von Wiederhol-Timern in Einmal-Timer.

Vielleicht hilft das weiter.

[flechumer]

Nachtrag: "ExcludeEvent" schließt Sendungen von der Verlängerungsfunktion aus, kommt also als Ursache nicht in Frage.

[chrisly]

Danke für Deine Hinweise!
AccTimers steht bei mir auf "N". Und auch die anderen Ursachen treffen in meinem Fall nicht zu. Deshalb gingen wir ja eigentlich auch Beide davon aus, dass AX mit der Löschung nichts zu tun hat. Aber die Tests haben ja gezeigt, dass AX wahrscheinlich doch der Übeltäter ist - allerdings ungewollt (BUG/Zusammenspiel mit anderen Taps?).
Da der Fehler nur in einer bestimmten Konstellation auftritt, werde ich aber nicht dauerhaft auf AX verzichten.
Evtl. fällt Dir ja irgendwann doch noch was auf, das als Ursache in Frage kommt. Derweil werde ich es weiter testen (mal mit, mal ohne AX). Falls es was Neues gibt und es sich herausstellt, dass AX doch "unschuldig" ist, werde ich mich wieder melden.