Stream-Monitor erkennt nicht das Stream offline ist

Bisher kannst Du für sowas nur nach dem Titel das Script zum Aktivieren per Dummy oder Command-Element setzen.

Dass mAirList einen Stream erkennt, aber erst nach dem Ende eines Titels startet, ist nicht als Standard implementiert - lässt sich aber vielleicht durch einen findigen Scripter lösen…

Ich denke, das wird schwierig.
Dazu müssten beide Instanzen sich ja in irgendeiner Art synchronisieren.
Soviel mir bekannt ist, ist das derzeit nicht möglich.

Ich verstehe es so, dass es hier um eine lokale Hauptinstanz geht, über die der (nicht zwangsweise mAirList-) Stream eingebunden werden soll - und zwar erst nach dem Ende eines Elements auf dem Server (das ja auch ein Jingle etc. sein kann (“und jetzt das Nachtprogramm mit…”), der den Stream übernimmt.

Vielleicht kann @HeyStivie das ja noch konkretisieren…

Ja, grundsätzlich bin ich bei dir.
Und das dürfte noch gehen.
Wo dann das Problem liegen dürfte, ist das dann der gewünschte stream auch genau danach startet, und nicht schon mitten im Titel oder Moderation ist.

Ich könnte mir auch vorstellen, daß man das hinskripten kann, aber genau das wird ein betriebliches Problem, weil keine Rückmeldung darüber stattfindet (stattfinden kann), wann genau der Stream online geht: jetzt, während der Blende, und wann da genau?

Idee dahinter war nur:

Das der Stream schon Live ist, aber Stumm, bis dann das Lied aus der Playlist zuende gelaufen ist. Danach soll dann erst der Ton vom Stream-Monitor kommen.

Das heißt, der Stream spielt schon.
Kann also folglich auch mitten im Titel dann zugeschalten werden?
Oder mitten in der Moderation ?

Korrekt. Die Playlist spielt.

Der Moderator connectet sich in Mitten eines Tracks auf den Server.
Die Automation beendet sich, die PL leert sich.

Nun wird das Lied, wo der Moderator sich connectet hat noch ausgespielt.

Meine Frage war: Kann man den Stream-Monitor so lange Stumm schalten, wie der Track noch ausläuft. Erst wenn der Track zu ende ist, soll der Stream-Monitor den Sound des Moderators ausspielen.

…und im Optimalfall löst diese “jetzt bin ich wirklich auf dem Stream”-Rückmeldung auf dem Senderechner des Moderators ein PLAYLIST 1 NEXT aus, womit die Sendung automatisch beginnt.
Stimmt’s?

1 Like

Dein Humor ist wirklich Bemerkenswert. Aber klar, wenn das geht :smiley:
Vllt. könnte man auch direkt ne AI Moderation mit einbauen :wink:

Humor hin oder her, mir ist immer noch nicht klar, wozu das ganze gut sein soll. Das Problem liegt eher in einer präzisen Musikplanung im vorhinein.

Nun, da ist ein großer Teil “persönlicher Wunsch” drin, der mit der Grundidee allerdings nicht viel zu tun hat.

  • Ein Script fragt ab, ob ein oder mehrere Encoder tatsächlich verbunden sind (die Grundlagen dafür sind im Forum bereits vorhanden).

    • Das Script wird entweder durch eine Uhrzeit getriggert (TOTH hh:00:00 beim Übergang aus der Automation; ich mag pünktliche Sendestarts)
      oder
    • eine manuelle Auslösung, wenn vorher ein anderer Moderator sendet. Da kann er herunterzählen wie er will (mir wurde von Sendesoftware berichtet, die kein vernünftiges Backtiming beherrscht): 10 Sekunden vorher versuche ich zu verbinden, was natürlich solange scheitert, bis der Stream frei ist und ich gewissermaßen exakt zum Ende der vorherigen Sendung automatisch connecte.
      Vorteil: Die Automation muss nicht dazwischenspringen, auch nicht für ein paar Sekunden.
  • Nachdem ich absolut sicher auf dem Stream bin, löst das PLAYLIST 1 NEXT mein erstes Audio-Element aus und, als Sahnehäubchen, zeigt mir das Script meinen Encoder-Status bestenfalls in einem erweiterten Button an (gab es hier auch schon im Forum).

  • Das Problem:
    Als Überwachungsscript eignet sich das wohl nicht, denn der Befehl PLAYLIST 1 NEXT soll ja nur zu Sendebeginn greifen, nicht aber während der Sendung. Daran knobele ich noch.

Das war der Abschnitt Uli, und der ist durchaus ernst gemeint.


Was du jetzt suchst, @HeyStivie, ist der Trigger für diesen “Starte Encoder, wenn (…)”.

Ich habe dich so verstanden:

  • Du “meldest” Sendebereitschaft, also möchtest gewissermaßen connecten. Das ginge auch, aber du möchtest, dass die Automation den aktuell laufenden Titel zu Ende spielt.

  • Beim Erreichen von FADE OUT des laufenden Titels auf dem Server soll der lokale Rechner den Encoder tatsächlich starten und damit gewissermaßen einen nahtlosen Übergang zwischen Server und lokalem Stream herstellen, ohne einen Automationstitel abzuwürgen.

Nach meinem Verständnis soll es so wie vorab beschrieben laufen: Aktuell spielenden Titel ordentlich beenden und den Übergang zum lokalen Stream gewissermaßen unhörbar machen.

Eine Variante kann sein, wenn auf dem Server TOTH Nachrichten laufen und deren Dauer unbekannt ist. Nach den Nachrichten soll dann die lokale Sendung ohne hörbare Umschalte starten.

Da bin ich ganz bei dir. Aber ich habe viele Stationen mit verschiedenen Varianten erlebt, die höchst unterschiedliche Ergebnisse erzielen. Sauberes Backtiming, korrektes TOTH-Management sowie präzise Einhaltung des Sendeplans, auch bei VP oder Wiederholungssendungen, darf als seltene Ausnahme angesehen werden.

Schön. Es wird also die Netto-Sendezeit des verbindenden Streams kürzer. Na ja. Und durch die fehlende Rückmeldung („jetzt kannst Du“) wird der Übergang auch nicht schöner, da nicht sicher ist, wann es tatsächlich losgehen kann.

Mein Rat: Pünktliches Backtiming, gerne mit eindeutigen Layoutelementen. Zwei Sekunden Schaltpause vorm Verbinden einplanen, daran stirbt keiner, und das Programm ist klar gegliedert.

Wider dem horror vacui!

2 Likes

Zutreffend.
Nun kann man das ja mit der Moderation abfangen (oder ein als Puffer überplantes Element fällt raus); im übrigen stammt aus deiner Feder ja auch das “stummes-Abfahren-Script”, dem man einen vergleichbaren Vorwurf machen könnte: Rette den pünktlichen Schluss der Sendung, weil ich gemäß Ablaufplan irgendwie zu lang geworden bin. :wink:

Im übrigen verfahren viele Moderatoren nach dem Motto “den letzten Titel spiele ich noch aus, auch wenn ich die Nettostunde überziehe” (war bei meinem vorletzten Sender gang und gäbe). Bitte unterschätze auch nicht die feststehenden (und meist viel zu langen) “Intros” und “Outros”, die ungeachtet eines Backtimings unbedingt ausgespielt werden müssen.

Ich kann jetzt zwar die Situation von @HeyStivie nicht einschätzen, aber ich schreibe als leidgeprüfter Hörer (und manchmal auch Moderator).

Nein, der letzte (geblendete) Titel gehört ja zur (gerade ausklingenden) Sendung dazu, und letztlich ist es egal, ob man ihn vorne oder hinten blendet. Da nicht einmal Profis ein pünktliches Backtiming hinbekommen (es sei denn, sie sind vom Schlage eines Reinke), ist es gang und gebe, gewisse Sendungselemente kontrolliert zu kürzen, um das Stundenende zu treffen. Sei es, indem ich einen „normalen“ Titel ausblende (die häßlichste aller Varianten), sei es, indem ich einen Instrumentaltitel dafür hernehme und hinten (na ja) oder vorne (schöner, genau dafür ist besagtes Skript) blende, oder eben, falls vorhanden, ein Layoutgeblubber einsetze und kleinblende.

Das ist Elementarwissen aus der Radiofibel.

1 Like

Es fehlt doch eigentlich nur der „Fingerzeig“ durch die Glasscheibe, um zwischen den Studios umzuschalten.

Abgesehen vom bereits sehr gut funktionierenden Studiomonitor von @ssnoopy , der vom folgenden Moderator wunderbar zum Erkennen des Titelendes/Stundenendes genutzt werden kann, bastelt er auch gerade an einem neuen Projekt, das für folgende Moderatoren ebenfalls sehr brauchbar sein kann, da hier sogar Titel remote verschoben werden können, um das Ende passender zu machen.

Klar, wer Bock auf Scripten hat und / oder Moderatoren die Eigenverantwortung nicht zumuten möchte, darf das machen. Eine simple Lösung wäre allerdings in Form von obigen Möglichkeiten schon da.

3 Likes

@ssnoopy Das ist ja mal der Oberhammer.

Neugierige Grüße

2 Likes