TAP: AutoExtender

[chrisly]

Ich verstehe es immer noch nicht ops:
AX verlängert doch die Aufnahmen (normalerweise) auch dann, wenn der Topf per Timer gestartet und später ausgeschaltet wird (das ist ja schließlich der Sinn). Durch AX wird das Ausschalten ja dann minutenweise um z.B. 10 Minuten hinausgezögert.
Das klappt ja auch meistens, aber warum hat es in o.g. Fall nicht geklappt (AX-Log: Abbruch)?

[flechumer]

Ich verstehe es immer noch nicht ops:
AX verlängert doch die Aufnahmen (normalerweise) auch dann, wenn der Topf per Timer gestartet und später ausgeschaltet wird (das ist ja schließlich der Sinn). Durch AX wird das Ausschalten ja dann minutenweise um z.B. 10 Minuten hinausgezögert.
Das klappt ja auch meistens, aber warum hat es in o.g. Fall nicht geklappt (AX-Log: Abbruch)?

Nicht AX hat in diesem Fall die Aufnahme beendet, sondern ex- oder implizit BootMenu. Das geht eindeutig aus dem Log hervor (Ursache = Abbruch). Das ist das gleiche, als wenn Du eine Aufnahme mit <Stop> <Stop> beendest. In so einem Fall kann AX die Beendigung nur registrieren aber nicht verhindern. Wär' ja auch noch schöner!

[chrisly]

Bootmenu übernimmt bei mir nicht das Abschalten. Dafür habe ich SDS im Einsatz. Ändert aber wohl auch nichts. Anscheinend ist das dann der Übeltäter. Schöner Mist ...

Aber AX ist damit wohl rehabilitiert ...

[chrisly]

Ich nochmal ...

Ich würde gerne noch etwas tiefer bohren: irgendwo im Zusammenspiel zwischen AX und SDS scheint ja das Problem zu liegen.
SDS schaltet den Topf aus, obwohl noch eine Aufnahme läuft, die AX eigentlich verlängert. SDS hat (soweit ich das beobachten konnte) noch nie während einer Aufnahme den Topf ausgeschaltet, sondern nur nach Ende der regulären Aufnahmezeit, die AX ja verlängern soll. Anscheinend erkennt SDS also nicht immer rechtzeitig die Verlängerung durch AX um jeweils 1 Minute.
Könnte man hier evtl. doch auf AX-Seite irgendwas so ändern, dass sichergestellt ist, dass SDS noch rechtzeitig auf die Verlängerung reagieren kann?

Ich weiß, dass das normalerweise der Fall ist, weil AX ja 1 Minute vor Ende um je 1 Minute verlängert. Aber ab und zu hakt es halt doch (bei AX oder SDS).
Aber vielleicht hast Du ja noch ´ne Idee!?

[flechumer]

Ich weiß, dass das normalerweise der Fall ist, weil AX ja 1 Minute vor Ende um je 1 Minute verlängert. Aber ab und zu hakt es halt doch (bei AX oder SDS).
Aber vielleicht hast Du ja noch ´ne Idee!?

Ganz einfach: Wer runterfahren will braucht nur zu prüfen, ob noch eine Aufnahme läuft. Das ist kein Problem.

Das mit der einen Minute vor Ende stimmt so nicht mehr. AX verlängert jetzt 2 Sek. vor Ablauf um eine Minute.

[Dixie]

@chrisly,
ich nutze SDS und AX (ältere Version ops: ) ja auch.

Der Topf zeigt nach Abschaltung bei meiner SDS-Einstellung die Restzeit bis zur Abschaltung an. z.B. OFF (-0.15)

Durch AX wird nach der regulären Aufanhmeendezeit bis zur Abschaltung wiederholt immer wieder OFF (-0.01) angezeigt.

Dixie

[chrisly]

@Dixie:
kam es bei Dir denn auch schon mal vor, dass eine Aufnahme nicht verlängert wurde?

Das mit der einen Minute vor Ende stimmt so nicht mehr. AX verlängert jetzt 2 Sek. vor Ablauf um eine Minute.

Eigentlich kann das ja auch nicht das Problem sein. Solange die Aufnahme noch läuft, erkennt das SDS ja auch (normalerweise). Aber könnte es sein, dass die 2 Sekunden "hart an der Grenze" sind und SDS damit manchmal nicht klar kommt?
Dann würde es ja evtl. helfen, ein paar Sekunden früher zu verlängern. Oder handelt man sich damit dann wieder andere Probleme ein?

[flechumer]

[quote="chrisly"]Eigentlich kann das ja auch nicht das Problem sein. Solange die Aufnahme noch läuft, erkennt das SDS ja auch (normalerweise). Aber könnte es sein, dass die 2 Sekunden "hart an der Grenze" sind und SDS damit manchmal nicht klar kommt?[/quote]

Hier kommt mal wieder die Logik ins Spiel. Wenn SDS oder Werauchimmer die Kontrolle erhält und über einen Shutdown entscheiden will, kann und darf es keine Rolle spielen, wie lang die restliche Aufnahmezeit ist. Was sagt eigentlich Firebird dazu?

[uenger]

Moin,
hab ich jetzt schon 2x erlebt:
Programmiere eine Aufnahme und vor Beginn dieser schaue irgendwas von der Festplatte.
Nachdem die Aufnahme genügend Vorlauf hat, um die lästige Werbung zu überspringen, beginne diese Aufnahme von Anbeginn zeit versetzt zu schauen. Geht alles prima und irgendwann erscheint dann das Fenster, dass die Aufnahme (einschl. Nachlauf) beendet wurde.
Schaut man jetzt in die Log-Datei, steht dort: Bookmarks= 2, tatsächlich werden diese jedoch bei mir dann nicht gesetzt. Ist das bei Euch in so einem Fall auch so?

LG
uenger

[FireBird]

[quote="flechumer"]Wenn SDS oder Werauchimmer die Kontrolle erhält und über einen Shutdown entscheiden will, kann und darf es keine Rolle spielen, wie lang die restliche Aufnahmezeit ist.[/quote]
So ist es auch. SDS wertet den vom Topf gemeldeten Aufnahmestatus aus. Solange zumindest einer der beiden Slots eine Aufnahme oder Kopie meldet, bleibt SDS in der Warteschleife.

Man kann in der ini-Datei den Debug-Level auf 2 setzen, dann gibt es eine SDS.log, die vielleicht weiteren Aufschluss geben kann.

[chrisly]

Dann sollte ich das wohl mal tun. Danke für den Hinweis!
Es kann zwar (zum Glück) länger dauern, bis das Problem wieder auftritt - aber ich werde es beobachten. Irgendwie muss die Ursache ja zu finden sein ...

[flechumer]

AutoExtender 02.09.66 steht online.

Änderung:
(1) Keine Timeranpassung bei ExcludeEvent
(1) Automatische Vorlaufanpassung bei Timer-Änderungen
Bugfix:
(1) Fehlerhafte Aufnahmedauer nach Vorlaufanpassung

[uenger]

Moin,

vielen Dank, natürlich schon drauf. :

LG
uenger

[Fritzcat]

Hatte in einer früheren Version auf dem 5500er schon mal das Problem, dass bei 3 aufeinander folgenden Aufnahmen die Meldung Timerkonflikt beim 3. Timer angezeigt wird, wenn die 1. Aufnahme startet.

In der Timerübersicht ist der 3. Timer beim Start der 1. Aufnahme mit 3 min Vorlauf versehen.

Hier mal die ini:

1. * Parameter = Wert Kommentar Vorbesetzung
   
   BookMarks = ja * ja/nein/j/n ja
   Extend = ja * ja/nein/j/n ja
   AccTimers = ja * ja/nein/j/n ja
   ConflictMan = ja * ja/nein/j/n ja
   PrePad = 3 * 0 ... 10 Min. 3
   ExtensionFrom = 0 * 0 ... 23 Std. 0
   ExtensionTo = 23 * 0 ... 23 Std. 23
   MaxExtension = 60 * 0 ... 120 Min. 60
   Delay = 10 * 0 ... 60 Min. 5
   AltDelay = "15, ZDF" * 0 ... 32 Einträge
   MaxTimerDelay = 5 * 0 ... 120 Min. 5
   TimerDev = 0 * 0 ... 120 Min. 0
   ScanTime = 04:00 * 0 ... 23:59 04:00
   LogBrowserKey = 2*0 * 2*0/weiß/weiss 2*0

Sollte ich an der ini etwas ändern oder woran liegt es?

[Fritzcat]

Nachtrag: Es passiert auch bei 2 Timern nacheinander auf dem selben Kanal

[flechumer]

[quote="Fritzcat"]Hatte in einer früheren Version auf dem 5500er schon mal das Problem, dass bei 3 aufeinander folgenden Aufnahmen die Meldung Timerkonflikt beim 3. Timer angezeigt wird, wenn die 1. Aufnahme startet.

In der Timerübersicht ist der 3. Timer beim Start der 1. Aufnahme mit 3 min Vorlauf versehen.Sollte ich an der ini etwas ändern oder woran liegt es?[/quote]

Es geht jetzt aber um die aktuelle Version, oder? Die Ini sieht jedenfalls ganz unverdächtig aus. Das Problem liegt daran, daß für eine Folgesendung ein Vorlauf erzeugt wurde. Das ist immer dann der Fall, wenn die Folgesendung vor der vorhergehenden programmiert wurde. Bei Programmierung über Standard-EPG ist die Sache einfach: Alle Sendungen hintereinander mit <rec> auswählen und den EPG verlassen. Dann versieht AX die erste Sendung mit Vorlauf, die Folgesendungen nicht. Wie die Reihenfolge bei EPG-TAPs aussieht, entzieht sich meiner Kenntnis. Es muß aber gehen, wenn man die richtige Reihenfolge erzwingt.

[Fritzcat]

Im Einsatz ist die aktuelle Version.
Programmiert habe ich mit Jag, bei dem weder Vor-/Nachlauf eingestellt ist.
Es wurde auch zuerst die erste Sendung, dann die nachfolgende(n) programmiert.

Rufe ich dann per Quicktimer die Timerliste auf, finde ich die erste Sendung mit Vorlauf 3 min (durch AX) und die folgende ohne Vorlauf. Erst beim Start der 1. Aufnahme kommt der Hinweis Timerkonflikt durch improbox. In der Timerliste fehlt dann die 2. programmierte Sendung, da ja beide Sendungen in einer Datei aufgenommen werden.

Schön wäre es natürlich, wenn der Timer dann auch gleich die Endzeit incl. der 2. Aufnahme anzeigen würde und der Titel beide Sendungsnahmen enthalten würde.

Ich weiss allerdings nicht ob das gehen würde.

Wichtiger wäre natürlich diese Fehlermeldung loszuwerden.

[flechumer]

Wenn ich das jetzt richtig verstanden habe, zeigt IB irgendwelche Timerkonflikte an. Dann solltest Du erst mal dort klären, was gemeint ist. Außerdem solltest Du mit der Topf-eigenen Timerübersicht die vorgesehenen Anfangs- und Endzeiten kontrollieren, um festzustellen, ob tatsächlich ein Konflikt besteht.

[Fritzcat]

Da ich das gleiche Problem mit einer Vorversion schon mal hatte s. hier und folgende, dachte ich, dass du möglicherweise wieder etwas verändert hast. Damals konnte die Konfliktanzeige in der Version .57(2) vermieden werden

[flechumer]

Da ich das gleiche Problem mit einer Vorversion schon mal hatte s. hier und folgende, dachte ich, dass du möglicherweise wieder etwas verändert hast. Damals konnte die Konfliktanzeige in der Version .57(2) vermieden werden

Alles klar. In der Tat gibt es eine Änderung in der aktuellen Version, die dafür sorgt, daß periodisch geprüft wird, ob ein Timer mit Vorlauf versehen werden kann - soweit das nicht schon geschehen ist. Der Sinn ist natürlich eine automatische Vorlaufanpassung, sobald die Bedingungen dafür gegeben sind. Wenn also ein Timer verhindert, daß ein anderer einen vollständigen Vorlauf bekommt und ersterer wird entfernt, so ist kein manueller Eingriff mehr erforderlich, um den Vorlauf zu vervollständigen.

Für AX ist das ganze kein Problem. Daß andere sich dazu Gedanken machen (IB), habe ich nicht berücksichtigt. Ich werde sehen, was sich machen läßt.