TAP: AutoExtender

[flechumer]

Moin allerseits,
leider kann ich mich aus privaten Gründen vorerst nicht um AX und SC kümmern. Ich bitte um Verständnis.

[chrisly]

Kein Problem. Danke für die Info.

Moin,
ne hab ich noch nicht. kann m.E. auch nicht funzen, wegen Vor- und Nachlaufzeiten.

LG
uenger

Doch - die Zeiten sind ja die echten Aufnahmezeiten lt. Timer. Und wenn eine Aufnahme wie im Bsp. nicht verlängert werden kann, weil eine weitere Aufnahme ansteht, verlängert AX auch nicht, gibt das aber in der LOG an.
Ohne BMs klappt´s ja auch ...
Deshalb ist´s auch nicht so dramatisch - nur "nice to have".
Bei Gelegenheit werde ich mal testen, ob´s ohne Overfly (dafür mit AX-BMs) auch passiert.

Edit: Gerade ausprobiert ohne Overfly. Ergebnis: 1x Absturz, 2x nicht.
Hilft also auch nicht wirklich weiter, deutet aber darauf hin, dass das Problem auch ohne Overfly auftritt.

[flechumer]

AutoExtender 02.09.65 steht jetzt online. Es enthält eine wichtige Fehlerkorrektur, interne Änderungen und eine neue Funktion. Hier ein Ausschnitt aus der Beschreibung:

Konflikt-Management

Die Programmierung von Timern wird vom PVR überwacht. Es können deshalb nicht mehr als zwei gleichzeitige Aufnahmen programmiert werden. Konflikte können aber trotzdem auftreten durch zusätzliche Direktaufnahmen oder nachträgliche Programmierung. Das kann dazu führen, daß Timer verlorengehen. AX kann das nicht grundsätzlich verhindern aber die durch Verlängerung und/oder Vorlauf verursachten Konflikte behandeln, sodaß u.U. ein Timer-Verlust verhindert werden kann. Mit dem Parameter ConflictMan = ja wird diese Funktion zur Verfügung gestellt.

Einem drohenden Konflikt mit Timer-Verlust wird mit zwei voneinander unabhängigen Methoden begegnet:

• Wird bei einer laufenden Aufnahme, bei der das Bezugs-Event noch nicht abgeschlossen ist, der Konflikt festgestellt, so wird ein anstehender Timer um jeweils eine Minute verschoben, soweit es die durch MaxTimerDelay angegebene Verzögerung erlaubt.
• Ist bei einer laufenden Aufnahme das Bezugs-Event bereits abgeschlossen, so wird diese Aufnahme im Konfliktfall vorzeitig beendet.

Beide Methoden sind gleichberechtigt - welche davon angewandt wird, hängt von der aktuellen Situation ab. Es versteht sich, daß die Parameter MaxTimerDelay und ProtectTimer wesentlichen Einfluß auf die Wirkung der Funktion haben.

Noch eine Bemerkung zur Situation beim TMS. Es ist höchst bedauerlich, daß Topfield auch mit der Beta-FW vom 24.03.10 noch keine Korrektur zum Problem „Falscher CurrentEvent bei Playback und Timeshift“ zustande gebracht hat. Die Einhaltung des TAP-APIs scheint für TF von geringer Bedeutung zu sein.

[chrisly]

Uiiiih. Hört sich gut an.

Vielen Dank für die neue Version!

[uenger]

Moin,
vielen Dank für die neue Version, hatte ich jetzt nicht erwartet.

LG
uenger

[goge]

Hi,
Danke für die neue Version.
Grüße
goge

[uenger]

Moin,

meine erste Aufnahme mit der.65 von gestern hatte keine Bookmarks, obwohl lt. Log-Datei diese vorhanden sein müssten. Daraufhin gestern gleich noch eine weitere Aufnahme gemacht und heute schon zwei weitere, alles bestens. Hatte ich übrigens bei der .64 auch bei der ersten Aufnahme und danach dann nicht wieder. Sieht bisher alles sehr vielversprechend aus.

LG
uenger

Hatte ich vorhin vergessen:
Welche FireBird-Lib werkelt jetzt in der .65 :

[flechumer]

meine erste Aufnahme mit der.65 von gestern hatte keine Bookmarks, obwohl lt. Log-Datei diese vorhanden sein müssten.

Welche FireBird-Lib werkelt jetzt in der .65 :

Was war der Zustand bei Beendigung der Aufnahme (Warten auf Standby, Live sehen, Timeshift, Playback)?

FB-Lib ist die aktuelle.

[uenger]

[quote="flechumer"]Was war der Zustand bei Beendigung der Aufnahme (Warten auf Standby, Live sehen, Timeshift, Playback)?

[/quote]

Moin,
weiss ich noch genau, es war Live sehen auf einem anderen Programm.

LG
uenger

[flechumer]

Weißt Du noch, wieviele Bookmarks im Log angegeben waren?

[uenger]

Ja, weiss ich noch -hab noch die Log-Datei einsehen können-, es hätten drei BM sein sollen.

LG
uenger

[chrisly]

Wo wir gerade bei den BMs sind ...

Hast Du auch schon mal probiert, was passiert, wenn eine Aufnahme läuft (z.B. 20 - 22 Uhr) und währenddessen eine weitere Aufnahme beendet wird (z.B. bis 20:15 Uhr) und noch eine Aufnahme sofort danach startet (ab 20:15 Uhr)?
Mein Topf stürzt dann reproduzierbar ab (auch schon mit älteren Versionen) - allerdings nur, wenn AX Bookmarks setzt (deshalb hatte ich auch früher - und jetzt wieder - die AX-BMs ausgeschaltet).
Evtl. spielt ja auch das Zusammenspiel mit Overfly eine Rolle, das auch BMs setzt. Komisch ist aber, dass das im Normalfall keine Probleme bereitet. Nur in o.g. Situationen.

@flechumer: kann man das evtl. noch irgendwie optimieren?

Wurde diesbezüglich mit der aktuellen Version auch was geändert? Dann würde ich es gerne mal wieder wagen, AX-BMs setzen zu lassen.

[flechumer]

[quote="chrisly"]Wurde diesbezüglich mit der aktuellen Version auch was geändert? Dann würde ich es gerne mal wieder wagen, AX-BMs setzen zu lassen.[/quote]

Die Zusammenhänge sind komplex, weshalb sich ein Test immer lohnt. Ich konnte Dein Problem übrigens auch mit der Vorversion nicht reproduzieren. Aber im Zusammenhang damit ist das Konflikt-Management entstanden.

[chrisly]

Na dann werde ich es einfach mal wieder wagen.
AX-BMs sind ja schon was Feines ...

[chrisly]

Bis jetzt sieht´s gut aus. Auch mit AX-BMs noch kein Absturz in beschriebener Situation.

Allerdings scheint sich ein altes Problem wieder zurückzumelden:
manchmal wurden einzelne Aufnahmen nicht geloggt und nicht verlängert.
Mit der aktuellen Version ist gestern eine Aufnahme wieder nicht verlängert worden - dafür aber immerhin geloggt (ist ja schon ein Fortschritt ... ).

Ratgeber Bauen:
Ausführung / Vorgabe: 16:14 - 16:45
Bezugsevent statisch: 16:15 - 16:45 (dyn: bis 16:44)
Verzögerung: 11:01
Beendigungsgrund: Abbruch
BMs: 1

Der Topf wurde lt. Bootmenü-LOG per Timer aus dem Standby gestartet und um 16:45 automatisch ausgeschaltet. Er wurde in dieser Zeit auch nicht manuell bedient. Um 17 Uhr startete er wieder für eine neue Aufnahme, die auch sauber lief.

Was kann zu dem Abbruch geführt haben?

[flechumer]

Der Topf wurde lt. Bootmenü-LOG per Timer aus dem Standby gestartet und um 16:45 automatisch ausgeschaltet. Er wurde in dieser Zeit auch nicht manuell bedient. Um 17 Uhr startete er wieder für eine neue Aufnahme, die auch sauber lief.

Was kann zu dem Abbruch geführt haben?

Die automatische Ausschaltung?

[chrisly]

Ja - aber warum hatte AX die Abschaltung nicht verzögert? Aktiv war es ja.

[flechumer]

[quote="chrisly"]Ja - aber warum hatte AX die Abschaltung nicht verzögert?[/quote]

Hat es doch - sonst gäbe es kein Log. Hier liegt wohl ein Mißverständnis vor: AX reagiert nur darauf, daß die Aufnahme extern beendet wurde. Die Verzögerung dient nur dazu, daß AX die Bookmarks schreiben und loggen kann.

[chrisly]

Ich meinte auch nicht die Verzögerung, um die Log zu schreiben, sondern die Verlängerung um 10 Minuten, die ich eigentlich erwartet hätte (und in der ini auch so vorgegeben ist).

[flechumer]

Da ist wohl noch ein Mißverständnis auszuräumen: AX toleriert selbstverständlich jede Art externer Aufnahmebeendigung und reagiert darauf. Egal, ob eine Aufnahme explizit durch Kommandoeingabe oder implizit durch Shutdown erfolgt - AX kann und soll das nicht ändern.

In dem Zusammenhang sei nochmal daran erinnert, daß AX nur bei expliziter Beendigung, eingeleitet mit <Stop>, sauber einen Lock setzen kann. Andere Arten der Beendigung sollten vermieden werden.