Sehr. Der Mini-Scheduler arbeitet da äußerst zuverlässig.
Im übrigen kannst du die Stunden ja auch im voraus erstellen lassen (dann entfällt der Punkt “Datenbank Playlist erstellen”, da bereits vorhanden - oder das Event wird ausgeführt, stellt fest, dass schon eine Playlist existiert), manuell überprüfen, speichern und stündlich nachladen lassen.
Alles kein Hexenwerk.
Prinzipiell ist es von dir ja gewünscht, @hbreloaded das zu deinem Sendungs start, das letzte Lied komplett rein passt bevor du deine Sendung beginnst. Wenn ich das so richtig verstanden habe…
Grundsätzlich ein guter ansatz und angenehm fürs Ohr.
Jedoch ist das auch eine Sache an die sich kaum ein Radio hält. Und das hat in deren Fall auch gute Gründe:
All diese Dinge können dazu führen das die Playliste sich verschiebt und das letzte Element nicht mehr in die Stunde passt, was aber auch nicht weiter schlimm ist.
Da du in deiner Rotation oder Playliste diese Elemente vermutlich nicht hast, ist es ein leichtes den Schluss der Rotation auf deine Bedürfnisse anzupassen.
Wie ich es oben mit Backtiming schon beschrieben habe.
Bleibt noch zu klären, warum der (sorry) “lächerliche”, aber dennoch entstehende zeitversatz von Sekunden bei einer 18 Stunden Playliste zb. überhaupt entsteht 
das würde mich auch interessieren.
Da steig ich komplett aus. Habe damit noch nie gearbeitet.
Was Backtiming an sich ist, weißt du aber, oder?
Nun ja, und dafür gibt es eben auch eine Timing-Option in mAirList (das ist der Pfeil, der nach oben zeigt).
@TomJumbo83 Kleiner Wermutstropfen: Das funktioniert natürlich nur mit zwei harten Fixzeiten, d.h. irgendwo im Programm musst du mal blenden, sonst haut’s net hin.
Schon klar…
Das hatte ich ja da schon beschrieben…
Ja, aber auch davor 
- und irgendwo muss der Übergang sein.
- Sollte ich mich täuschen? -
Soweit ich weiß klappt es nicht, wenn du eine Playlist konfigurierst mit…
00:00:00 News-Container, harte Fixzeit01:00:00 Stundenende, harte FixzeitOder ist das schon mal jemand gelungen und ich denke hier gerade falsch?
Einen Übergang wird es immer geben… irgendwo muss auch mal ein Titel abgeschnitten sein. Und wenn es der vorletzte in Sachen Backtiming ist.
Das kann ich natülich nicht auf die ganze Stunde beziehen… das ist klar. So war auch nicht mein gedanke.
@hbreloaded prinzipiell sollte man sich auch mehr mit den Themen einer Radio Automation ein wenig beschäfftigen. Auch wenn es für dich momentan wie Böhmische Dörfer klingt ( …oder ein Traum?..)
lerne auch ich jeden Tag noch dazu.
Es gibt keine Regeln wie man Radio machen sollte oder muss… (ein kleines “leider” kann man da schon heraushören ) aber jeder fängt mal klein an.
Zumal wenn man nie in den Genuss gekommen ist, mit mAirlist auch mal in einem Funkhaus gestanden zu haben wie ich es durfte. Dort sieht man erst das wirkliche Potenzial des Programms.
Übrigends lernte ich dort damals auch nur die Basics was für den laufenden Moderierenden Betrieb wichtig ist.
Jetzt als “Programmchef” sieht die Sache schon ganz anders aus. Aber das soll niemanden abschrecken. Nur Mut… wie gesagt können wir uns gerne mal zusammensetzen und ich erkläre dir die Grundelemente. 
Ich bin für jede Hilfe dankbar.
Hallo,
ich würde mich da gerne mal einklinken.
Ich kann leider nicht mit einer Lösung beitragen, aber doch meine Beobachtungen und Erfahrungen weitergeben, damit gemeinsam vielleicht ein wenig Licht ins Dunkel gebracht werden kann… oder noch mehr Fragen aufgeworfen werden… (?)
Wir arbeiten mit Stunden Playlisten, vom Mini Scheduler erzeugt und danach von Hand feingetuned (inhaltlich), die im Auto-Modus ausgespielt werden. Playlisten liegen im Netzwerk in der DB und zwei mAirList Instanzen auf getrennten Rechner greifen darauf zu und machen redundantes Playout.
Die beiden Rechner sind über NTP synchronisiert, haben also die identische Systemzeit.
Wir haben nur eine (1) harte Fixzeit pro Tag, immer in der späten Nacht wenn wenig Zuhörer zu erwarten sind. Klassische Musik, keine Nachrichten, Werbung oder sonstiges, was ein exaktes Timing erfordert.
Nun ergibt es sich aber, dass die beiden mAirList Instanzen, die übrigens absolut identisch konfiguriert sind, innerhalb von 10-12 Stunden um einige Sekunden (meist etwa 6 bis 16 Sekunden) auseinander laufen.
Und hier frage ich mich nun auch, woran das liegen kann?
Wir haben keine Trennung der Internetleitung, die Logs sind auf beiden Rechnern identisch, es passiert nicht, was das erklären könnte, zumindest finde ich nichts…
Ist das eventuell das gleiche “Problem”?
Klar: ein, zwei harte Fixzeiten mehr und es versendet sich in der Messtoleranz.
Aber eigentlich…
Abendliche Grüße
Im Grunde ja. Man kann sagen, dass sich die Playlist pro Stunde um 1-2 Sekunden nach hinten verschiebt.
Selbst bei einer komplett durchgeplanten Liveshow mit einer Dauer von einer Stunde habe ich letztens beobachtet, dass sich die Playlist um eine Sekunde verschoben hat. Ich weiß, eine Sekunde ist nichts, aber mich würde dennoch der Grund für die Verschiebung interessieren.
Der Grund dahinter würde mich zwar interessieren, jedoch muss ich ganz ehrlich sagen das es mich und allgemein mein Radio Betrieb nicht betrifft.
Ich arbeite mit Stundenvorlagen die genau eine Stunde lang sind. Jeweils zum Stundenanfang kommt ein Uhrzeitjingle (Zeitansage) und der vorherige Titel, der in der “alten” Stunde läuft, wird abgewürgt.
Auch wenns unverständlich vlt klingt ist das aber in jeder terrestrischen Station ganz normal. Grund hierfür ist nicht die Gleichgültigkeit der Sender sondern News Content und Werbung die laufen müssen um Geld zu verdienen. Also unerlässlich für dessen Stationen sind.
Und Plump gesagt orientiere ich mich danach. Nur eben ohne Werbung
Ungeachtet dessen hab ich mal irgendwo in der vergangenheit mitbekommen das sich Fade/Cuepunkte in Tracks im Millisekunden Bereich, also 0,002 oder so verschieben können, bzw die Berechnung der tatsächlichen Spielplänge der Playliste verhadern kann. Gerechnet auf 12 oder gar 24 Stunden kann da gut mal eine ganze Sekunde zusammen kommen.
Da ich grad mobil bin, bin ich zu faul den Beitrag grad rauszusuchen. 
Es bleibt ja nicht bei einer Sekunde pro 24 Stunden. Wir sprechen hier von bis zu 30sec pro 24 Stunden.
Angenommen, dass es sich um einen echten Bug handelt (ich müsste mal prüfen, ob das in den Bereich möglicher Rundungsfehler passen könnte): Gravierend scheint der nicht zu sein, sonst hätten wir mit anderen, größeren Kunden (terrestrische Lokalradios, DAB+ etc.) ernsthafte Probleme.
Aber aus der Richtung kommen keine diesbezüglichen Beschwerden.
Das könnte auch mit dem klassischen Radio-Workflow zusammenhängen:
Ich respektiere ja deinen Wunsch, aber nach vielen Kundengesprächen sehe ich auch, dass deine Idee nach meiner Wahrnehmung recht selten “da draußen” anzutreffen ist.
Aber ich werde mal versuchen, das nachzustellen. Wie lauten die Anforderungen? Ich bastel’ mir eine lange Playlist, und wie geht es dann weiter? Welches Phänomen soll ich im Test wie beobachten können? Wie kann ich das nachvollziehen, ohne eine Nacht vor dem Rechner sitzen zu müssen?
Eine Playlist mit einer Länge von 12 bis 18 Stunden ins Ausspielfenster ziehen und am Ende der Playlist einen Platzhalter mit der rechts oben angezeigten Endzeit der Playlist als Name erstellen (z.B. 18:23:12). Die Playlist im Automodus durchlaufen lassen und nach den 12 bis 18 Stunden schauen, was im Platzhalter steht und was das tatsächliche Ende des letzten Elements ist.
Vielen Dank. Möglicherweise komme ich später dazu.
Blitzumfrage an die anderen hier mitlesenden und schreibenden Radiomacher:
Ist das praxisgerecht? Macht ihr das auch so?
Bitte notieren, wieviele Elemente diese Playlist enthält.
Gezählte Grüße
TSD
Wie ich es mache steht ja schon ausführlich im Verlauf der Unterhaltung
Same here, @TomJumbo83.
Ich kam nur drauf, weil ich vorhin am Telefon einem unserer Kunden bei einem Plausch (hüstel) das Problem grob umriss und er einen solchen Anwendungsfall einfach nicht nachvollziehen konnte.
Andererseits möchte ich @hbreloaded ernst nehmen, um einen möglichen Fehler zu finden.
Mein Verdacht: Die Mehrzahl unserer Anwender arbeitet nicht so, dass es jemals “sendungsgefährdend” auffällig geworden wäre.
Daher hatte das, sofern es überhaupt ein Bug sein sollte, nie wirklich Priorität.
Jetzt ist es schon eine Weile her, aber ich antworte hier nochmal:
In unserem Fall ist es keine lange Playlist, die für das Phänomen sorgt.
Wir verwenden Stundenplaylists, die leicht überplant sind (im Bereich von einigen Sekunden bis wenigen Minuten). Jede Playlist enthält grob zwischen 3 und 20 Elementen.
Allerdings orientieren wir uns nicht an den durch Werbung und Nachrichten erforderlichen Gepflogenheiten und haben daher nur eine einzige harte Fixzeit am Tag.
Das heisst, dass natürlich im Laufe des Tages Stundenende und Stundenbeginn nicht mehr exakt auf der vollen Stunde liegen. Das stört uns aber nicht.
Mir fällt eben nur auf, dass die Verschiebung, die sich daaurch ergibt, bei den beiden redundanten Playout Instanzen unterschiedlich ist. Die identisch konfigurierten Playout Instanzen berechnen also an irgendeiner Stelle und aus irgendeinem Grund unterschiedlich…
Wir gehen damit dann parallel auf zwei getrennte Ingest Server und weiter ins CDN.
Wenn nun für Wartung, aufgrund Ausfall eines Rechners oder was weiß ich, zwischen den beiden Streams gewechselt wird, gibt es halt einen deutlichen Sprung im Programm.
Das ist sicher für unsere Hörer kein Kriterium gleich abzuschalten oder den Sender zu wechseln, aber dennoch frage ich mich halt, wie es dazu kommt.
Ich verstehe aber, wenn die weitere Untersuchung aus Kosten- und Relevanzgründen eher weiter unten auf der ToDo Liste angesiedelt ist