Timing: Zusätzlich zu Fixzeiten auch "geplante Zeit"?

[StefanE]

Ich bin mir nicht sicher, ob ich das folgende richtig denke.

Für einige Elemente möchte ich gerne angeben, zu welcher Zeit sie laufen sollen, sagen wir eine bestimmte Rubrik um ca. 16:20 Uhr. Dafür gibt’s ja die Fixzeiten. Da es nicht auf die genaue Minute ankommt, wähle ich die weiche Fixzeit. Soweit so gut – wenn die Rubrik dort tatsächlich laufen kann.

Wenn ich nun auf Sendung bin und die Automation einschalte, können aber ungewollte Dinge passieren.

Zum Beispiel so:
Ich bin im Assist-Modus. Es ist 16:19. Nun verspätet sich die Rubrik (Leitung für die Reporterschalte ist noch mal zusammengebrochen oder ähnliches). Also ziehe ich noch schnell einen Musiktitel vor die Rubrik. Mache ich nun die Automation an, fliegt der gerade vorgezogene Titel aber aus der Playlist raus, weil ja die Rubrik die weiche Fixzeit 16:20 hat. Und zack läuft die Verpackung der Rubrik los.

Um das zu umgehen müsste ich die Fixzeit der Rubrik ändern oder das Timing auf “Normal” umstellen. Im Eifer des Gefechts ist das aber zu umständlich.

Andere Lösung: Ich setze die Rubrik von vorne herein auf “Normal”. Das ist aber auch nicht schön, denn dann funktioniert die Anzeige von Sendelöchern etc. nicht – und ich sehe nicht, wann die Rubrik eigentlich laufen soll.

Vielleicht habe ich irgendeine Kombination aus “Auf das Erreichen von Fixzeiten warten” und der Angabe “Zeitfenster” beim Timing noch nicht bedacht?

Ich überlege, ob ein zusätzlicher Timing-Modus nötig ist, um das hinzukriegen, etwa “Timing normal mit Planzeit”. Obwohl das Element “normal” behandelt wird, werden Sendelöcher etc. so angezeigt wie bei Elementen mit Fixzeiten. Wenn ich aber was davor ziehe, wird die neue Zeit angezeigt (evtl. noch eine Angabe dazu “+ mm:ss”).

Oder hab ich nur nen Knoten im Hirn?
Falls ich keinen Knoten im Hirn habe, wäre das “Timing normal mit Planzeit” ein Feature-Request.

[StefanE]

Inzwischen habe ich die Lösung gefunden, also antworte ich mal selbst, falls jemand anderes auch mal diesen Knoten im Hirn hat.

Es ist eigentlich ganz einfach. Die Lösung lautet:
Playlist → Optionen → Im Automations-Modus automatisch zu Fixzeit-Elementen springen → deaktivieren

Damit passiert genau das nicht mehr, was mich gestört hat.

Wir haben jetzt – für mehr Klarheit für die Benutzer und zum einfacheren Umschalten – einen Erweiterten Button gebaut mit den beiden Funktionen:
OFF: Halbautomatische Automation (Fixzeiten ignorieren) (grün) → PLAYLIST 1 OPTION HandleFixedTime OFF
ON: Vollautomatische Automation (Fixzeiten berücksichtigen) (rot) → PLAYLIST 1 OPTION HandleFixedTime ON

Die Halbautomatik verwenden wir fortan normalerweise, die Vollautomatik nur im Nachtbetrieb u.ä., wenn also tatsächlich niemand im Studio ist.

Ist jetzt glaube im Endeffekt nichts neues. Wir waren einfach nur zu blind, die Funktion zu finden. Fragt nicht, warum. :-}

[Torben]

Ich hatte nach deinem Post (sorry, nicht geantwortet) auch ein wenig gegrübelt, wie man das wohl lösen könnte. Im Prinzip hast du schon recht, man braucht einen Modus, in dem zwar berechnet aber nicht gesprungen wird.

Auf die Idee mit der Option bin ich aber selbst bislang nicht gekommen, obwohl es doch so naheliegent ist

[StefanE]

Mit dem Umschalten der Playout-Playlisten in “Halb- und Vollautomatik” (wie wir es jetzt genannt haben) ist das Problem ja erstmal gelöst.

Es könnte aber sein, dass sich grundsätzlich zusätzlich zu den Fixzeiten eine “Planzeit” o.ä. lohnen könnte einzuführen. Die hätte dann wirklich nur die Funktion z.B. dass Sendelöcher angezeigt werden - und man weiß, wann das Element planmäßig laufen soll. Das wäre dann sozusagen ein Element mit “butterweicher Fixzeit”.

[StefanE]

Hi Torben,

eigentlich dachte ich, das Problem wäre wie oben in diesem Thread beschrieben, gelöst. Aber etwas funktioniert noch nicht richtig. Ich vermute einen Bug, bin mir aber nicht sicher, wie es von Dir vorgesehen ist:

Das Problem ist, dass mAirList im AUTO-Modus die Länge von Musikbetten u.ä. berücksichtigt WÄHREND SIE LAUFEN, obwohl sie als “vom Backtiming ausnehmen” markiert sind. Dadurch entsteht folgendes Problem:

Beispiel: Nachrichten mit Wetter und Verkehr. Sie sind mit einem Platzhalter für 5 Minuten im Sendeplan vorgesehen. Danach folgt die Verpackung der Nachrichten (Opener, Stinger, Automationsunterbrechung (für die Meldungen ohne Bett), Bumper Verkehr, alle vom Backtiming ausgenommen) und der Opener der Sendung (vom Backtiming ausgenommen), danach Musik. Für z.B. :15 ist eine Rubrik mit weicher Fixzeit geplant.

Das sieht alles gut aus, solange die Nachrichtenverpackung nicht läuft. Wenn ich nun den Bumper Verkehr starte, der ein Bett mit 10 Minuten Länge beinhaltet, und die Automation einschalte, dann überspringt er bei Druck auf NEXT alle folgende Elemente bis zur Rubrik um :15 Uhr, weil er offenbar denkt, dass der Verkehrsbumper ja nun 10 Minuten läuft. Folglich wirft er alles andere raus, sonst läuft die Rubrik nicht zur rechten Zeit. Das ist aber falsch gedacht.

Wenn der Verkehrsbumper gerade mal 20 Sekunden gelaufen ist, sollte die Automation wissen, dass sie die anderen Elemente noch problemlos spielen kann, wenn ich die NEXT-Taste drücke. Der auf den Verkehr folgende Opener der Sendung sollte weiterhin als nächstes Element markiert sein. Schließlich ist ja noch genug Zeit.

Haben wir eine Option übersehen die wir aktivieren oder deaktivieren müssen?

Derzeit ist es so: Aktivieren wir die Automation und drücken NEXT, fliegen uns 15 Minuten der Sendung raus und die Rubrik um :15 kommt. Das ist nicht praktikabel.

Ist es doch ein Bug?

[StefanE]

Nachtrag: Wenn ich so nochmal lesen, was ich vor einigen Wochen geschrieben habe, kommt mir der Gedanke: Kann es sein, dass die Option HandleFixedTime kaputt ist? Wir haben sie ja nun standardmäßig auf OFF gesetzt. Dann dürfte doch eigentlich das von mir eben beschriebene Problem gar nicht mehr auftreten, oder?

Etwas verwirrte Grüße aus Butzbach
Stefan

[StefanE]

Ich habe es gerade noch mal ausprobiert. mAirList macht derzeit keinen Unterschied im Verhalten zwischen HandleFixedTime ON und OFF.

v5.1.3.2788

---

[Torben]

@StefanE

Wenn ich nun den Bumper Verkehr starte, der ein Bett mit 10 Minuten Länge beinhaltet, und die Automation einschalte, dann überspringt er bei Druck auf NEXT alle folgende Elemente bis zur Rubrik um :15 Uhr, weil er offenbar denkt, dass der Verkehrsbumper ja nun 10 Minuten läuft.

Das ist ein bekannter Bug, der sich leider nicht ohne weiteres beheben lässt.

Dazu muss man verstehen, wie der Automations-Algorithmus intern arbeitet:

Bei jeder Status-Änderung der Playlist oder Player schaut der Algorithmus, ob gerade “alles in Ordnung” ist, also ob mindestens ein Player spielt - wenn nein, sucht er das nächste zu spielende Element, lädt es in einen Player und startet diesen.

Der Algorithmus verlässt sich dabei auf die Informationen, die ihm der Backtiming-Algorithmus - der ebenfalls bei jeder Änderung angestoßen wird, und zwar vor dem Auto-Algorithmus - hinterlegt hat. Insbesondere das “overflow”-Flag, das anzeigt, dass ein Titel aufgrund einer folgenden Fixzeit übersprungen wird. (In der GUI als ausgegraut gekennzeichnet.)

Der Automations-Algorithmus muss sich also nicht selbst um Fixzeiten und all das kümmern, sondern er verlässt sich einfach auf das, was der Backtiming-Algorithmus für ihn ermittelt hat. Auf diese Weise funktionieren z.B. weiche Fixzeiten “ganz von alleine”.

Was passiert nun beim Klick auf NEXT?

Es werden einfach alle laufenden Player ausgefadet, und dann springt der Automations-Algorithmus an, wie oben beschrieben. Der such sich das nächste Element (das nicht overflow ist) und spielt es.

Leider ist das in dieser Situation falsch, denn beim manuellen NEXT will man in der Regel zum unmittelbar nächsten Element springen.

Die Lösung könnte also darin bestehen, das overflow-Flag in dieser Situation einfach zu ignorieren. Ich will mal schauen, ob sich das bewerkstelligen lässt.

[StefanE]

Danke für die ausführlichen Erläuterungen. Ich verstehe das wohl nun ungefähr.

Allerdings versuche ich jetzt in diesem Zusammenhang noch den Unterschied zwischen HandleFixedTime OFF und ON zu verstehen.
Wenn ich es richtig sehe, ist der einzige Unterschied, dass die Automation bei HFT OFF das Bett 10 Minuten lang zuende spielen würde, in dem Moment, in dem es endet bzw. ich auf NEXT drücke, bemerkt das Backtiming, dass es höchste Zeit für den Opener ist und springt deshalb dann dorthin.
Wenn hingegen HFT ON ist, springt er in dem Moment, in dem die Uhrzeit auf 15:00 wechselt, sofort zum Opener, weil dann das Backtiming NEXT selbständig auführt.
Hab ich das so richtig verstanden?

Dann bräuchte es doch jetzt “nur noch” eine Option, wie Du sie beschrieben hast, etwa HandleOverflow ON/OFF.

Dann ergeben sich nach meiner Überlegung 3 Automationsstufen:

3. Voll-Automat = HandleOverflow ON & HandleFixedTime ON

4. ¾-Automat = HandleOverflow ON & HandleFixedTime OFF

5. Halb-Automat = HandleOverflow OFF & HandleFixedTime OFF

6. Assist

Ich frage mich allerdings, ob es einen Fall gibt, in dem man Variante 2 überhaupt in der Praxis braucht!?

Ist in den Überlegungen aber nicht auch wichtig, dass es sich bei den Musikbetten um Elemente handelt, die als “Vom Backtiming ausnehmen” gekennzeichnet sind? Wäre es ein Musiktitel (mit normalem Backtiming), dann wäre es ja richtig, wenn die Automation sich so verhält wie bisher. Meiner Ansicht nach ist der Knackpunkt, dass das Backtiming hier das Bett nicht wie ein laufendes Element betrachten darf. Das Bett hat ja quasi keine Länge, es verbraucht keine Zeit. Während ein Bett läuft, müsste das Backtiming so denken, wie wenn die Automation gerade angehalten ist und ohne Bett moderiert würde.

Dann bräuchte es doch keinen Modus HandleOverflow, sondern es bräuchte eben nur diese Unterscheidung bei Elementen, die vom Backtiming ausgenommen sind.
Oder mache ich jetzt einen Denkfehler?

Viele Grüße aus Butzbach
Stefan

[i]PS: Ich hatte in der Vergangenheit schon immer mal ein Problem, wenn ich ein Element mit Fixzeit in eine Playlist geladen hatte und es um 30 Minuten nach unten verschoben habe. Da ist mir schon manchmal die halbe Playlist während der Sendung um die Ohren geflogen, wenn ich die Automation eingeschaltet habe, um nach nebenan in die Redaktion zu gehen oder ein Interview aufzeichnen wollte. Aber das war nur ab und zu mal.

Nun wird das aber ein größeres Problem, weil wir in diesem Jahr eigentlich Formatvorgaben etc. über die Stundenvorlagen vorplanen wollen. Damit bekommen die Elemente aber harte und weiche Fixzeiten. Aber so, wie es jetzt funktioniert, können wir das gar nicht nutzen, es sei denn, wir deaktivieren die Automation vollständig und fahren nur noch im Assist-Modus.

Machen wir was falsch? Es müssten doch noch viel mehr Leute solche Probleme haben?[/i]

[StefanE]

Hi zusammen,

Snapshot - Build 2792 […] [-] Automation: Skips overflow items on manual NEXT

Wir haben das gestern ausprobiert. Ja, nun ist es so, dass bei Druck auf NEXT im AUTO-Modus nichts übersprungen wird sondern das nächste Element in der Playliste gespielt wird.
ABER: So ergibt es auch noch nicht wirklich Sinn, denn angezeigt wird ja weiterhin, dass die nächsten Elemente übersprungen werden. Die Markierung des nächsten Elements und in den Player geladen ist ein anderes als das, was durch Druck auf NEXT gestartet wird. Das ist natürlich ganz verwirrend. Würde ich nicht empfehlen so drin zu lassen, denn so ist es irgendwie ein Workaround, aber es beseitigt nicht das eigentliche Problem.

Daher noch mal die direkte Frage: Was genau ist der Unterschied zwischen HandleFixedTime ON und OFF?

Ich hatte die Funktion neulich ursprünglich so verstanden, dass bei OFF einfach ein Element nach dem anderen vollständig von der Automation abgespielt wird, egal ob es einen Overflow gibt oder nicht. Denn er soll ja die Fixzeiten NICHT BEHANDELN.
Bei ON hingegen überspringt er bei einem Overflow die Elemente, die zu viel sind, und berücksichtigt die Fixzeit. Bei harten Fixzeiten sofort, bei weichen wartet er ab, bis das aktuelle Element zuende gelaufen ist.

Unser Problem: Der HFT OFF macht das im Moment so nicht. Dabei hatte ich vor ein paar Wochen (füherer Build, siehe Posting vom 08.06.2015) den Eindruck, dass er genau so funktioniert.
Frage an Torben: Hast Du seitdem noch mal etwas geändert? Oder hatten wir einfach nicht den Fall damals ausprobiert, den wir jetzt getestet haben?

Wenn HFT OFF so funktionieren würde, wie von mir beschrieben, dann würde das bedeuten, dass in diesem Modus die Fixzeiten nur noch die Funktion von Planzeiten hätten, sodass man z.B. Sendelöcher sieht. Damit würden sich alle anderen Überlegungen bezüglich “Planzeiten” etc. erledigen.
Es gibt dann - wie bei uns ja seit dem 08.06. eingeführt - einen Automationsmodus mit HFT OFF, wenn der Moderator kurz für ein paar Minuten mal vom ASSIST in den AUTO-Modus umschaltet, mAirList arbeitet aber einfach eins nach dem anderen ab. Für vollautomatische Nächte etc., wenn es wichtig ist, dass Fixzeiten eingehalten werden, wird HFT ON geschaltet.
Mit den bekannten Funktionen “auf harte Fixzeiten warten ON/OFF” und “auf weiche Fixzeiten warten ON/OFF” hat man dann eigentlich fast alles, was das Herz begehrt.

Also: Die eine zentrale Frage könnte vielleicht den großen Knoten lösen. Was meint der geschätzte Programmierer?

PS: Unser Workaround jetzt für unsere Stundenvorlagen: Wir arbeiten nun ausschließlich OHNE Fixzeiten. Es gibt nur normale Elemente und Elemente, die vom Backtiming ausgenommen sind. Damit umgehen wir das Problem, das sich derzeit im AUTO-Modus ergibt. Etwas umständlich dabei: Beim Anlegen der Stundenvorlagen müssen wir die Längen von Musikblöcken von Hand ausrechnen, anstatt einfach vor einem Fixzeitelement einen Block zum Auffüllen einzufügen.

---