Hallo zusammen,
wir verwenden den Nachrichten Container um täglich regionale Neuigkeiten automatisiert ausspielen zu können.
Den Nachrichten Container deswegen, weil wir damit auch ein Musikbett unterlegen können.
Insgesamt hab ich dafür in der DB 55 Container angelegt die jeweils mit bestimmten Dateien jeden Tag ergänzt werden.
- Hierbei wird immer die selbe Datei überschrieben. Es sollte sich also genauso wie bei zugelieferten Nachrichten verhalten.
Zum erstellen aller Container hab ich eine Dummy Datei verwendet die etwa 2 Sekunden lang ist.
Sobald aber Updates kommen, wird die Länge des Containers in der Datenbank selbst, nicht verändert. Erst wenn ich diesen in der Playliste abspiele, steht die neue länge fest.
Problem:
Dadurch das bei der Playlisterstellung die alte (ursprungs-) Länge noch in der Datenbank steht, werden für die Planung auch die Zeiten entsprechend von gerade mal 2 Sekunden berücksichtigt. Das ist insofern schade, als dann die tatsächliche Spiellänge bei mehreren Elementen in der Playliste der jeweiligen Stunde alle Elemente unvorhergesehen nach hinten verschoben werden.
Soweit das dadurch am Stundenende sogar Elemente aus der Stunde heraus fallen.
Fragen
- Gibt es eine Möglichkeit, die Längenangaben der Container dauerhaft in die Datenbank zu schreiben?
Selbst über die Funktion:
- Massenbearbeitung - Länge Ermitteln lässt sich das Problem nicht beheben
Die Längen in der Datenbank bleiben so kurz wie am Anfang
Der Newsblock ist vom Prinzip her dafür gedacht, dass er quasi spontan die Newsinhalte ausliest, die in der Stunde vorher hochgeladen wurden. Eine exakte Planung beim Generieren der Playliste ein paar Stunden oder Tage im Voraus würde das ja konterkarieren.
Es müsste für eure Anforderung also einen neuen Typ Container mit Opener, Bett, Trenner und Closer geben, der bei der Planung bereits ausgelesen und dessen Länge dann aktuell in der dB festgeschrieben wird.
(Aber was ist, wenn der Inhalt dann doch noch mal geändert wurde vor der Ausspielung? Dann würde er sich nicht mehr variabel anpassen.)
Für die Planungssicherheit gibt es ja bei Stationen eigentlich ein Zeitfenster, auf das die Editoren exakt schneiden/sprechen, damit das immer passt.
Kurze Frage: Warum hast Du ein Dummy-Element von nur 2 Sekunden eingeplant, die ja zum Planen benutzt werden?
Ihr werdet ja ungefähr wissen, wie lang der Inhalt/Beitrag in der Regel ist. Setze ein Element ein, das etwas länger ist und Luft bietet, dann füllt sich beim Laden der Playliste der entstandene Raum im Zweifel mit weiterer Musik aus einem Block auf. Also bei Regellänge von 2 Minuten → 2:15
Das wäre zumindest ein Workaround.
Hast Du schon versucht, wichtige Elemente am Stundenende Backtimed vom Stundenende aus zu planen? Dann fliegen sie auch nicht raus, sondern höchstens ein Titel aus einem Musikblock davor.
Jetzt im Nachhinein Frage ich mich das auch 
Naja die Beiträge sind etwa 1:30 - 2:00 lang. In seltenen Fällen noch länger.
Ich hab zumindest mal darüber nach gedacht, jedoch würde das bei bis zu 10 Elementen in der Stunde dennoch irgendwo crashen oder unschön werden.
Eventuell würde ein Script, das zur Nachbearbeitung in der Stunde eingebunden wurde, dafür sorgen können, das die längen zumindest nach der Playlist Erstellung stimmen. 
Als krönung danach in die DB Elemente geschrieben werden.
Ach ja, die Container laufen in der Stunde verteilt und nicht als Block. Wichtig eventuell zu erwähnen
Mir würde es theoretisch helfen, ein Script zu haben, das stündlich bsteimmte Container mit einer festen ID in der Datenbank überprüft und dessen Länge aktualisiert. (bevor die Stunde generiert wird) Würde soetwas gehen?
