Hallo in die Runde, wir bräuchten etwas Unterstützung.
Wir möchten einen externen Stream zu gegebener Zeit in unser Programm einbinden. Dafür ist wohl der Stream Monitor zuständig.
Wir haben zwei Streaming Adressen (Icecast) die wir von unserem Provider erhalten haben. Einen auf dem das Programm läuft und einen zweiten für Testzwecke. Den für Testzwecke würden wir nun für die externe Einspielung nehmen (High Priority). Wie muss die korrekte Adresse lauten, damit der Monitor den Teststream abfragen kann (IP, Port, Mountpoint)?
Ich habe einige Beiträge gelesen, komme aber nicht weiter. Und was wäre ein technisch sauberes Prozedere im Umgang mit externen Streams (Moderatoren-Server?).
Vorab schon mal Danke für Infos
Karl-Heinz
Keine Ahnung, die Datenbank und Vorlagen ist eher Dein Thema 
Moin Harl-Heinz,
ich denke an der Stelle ist der Stream Monitor evtl. das Falsche Werkzeug. Wenn Du von einem externen Dienstleister eine Sendung übernimmst, würde ich das lieber über den MiniScheduler mit in den Programmplan einplanen lassen.
Der Stream Monitor ist eher ein Werkzeug um die Einspeisung Deiner Moderatoren besser zu kontrollieren, die das laufende Tagesprogramm für Ihre Live-einspeisung unterbrechen und im Anschluss läuft die Tagesrotation weiter. Das würde ich nur nutzen, wenn ich auch selber den Streamserver unter Kontrolle habe, über den die Einspeisung läuft. Früher hat man das so gemacht, dass man die Automation runter kickt um selber zu senden und im Anschluss hat sich der “AutoDJ” (ich hasse diesen Begriff) wieder automatisch verbunden.
Mal angenommen auf der Streamadresse die Du bekommen hast werden zu anderen Zeiten noch andere Sendungen übertragen, dann würden die auch Dein laufendes Tagesprogramm unterbrechen, wenn Du den Stream Monitor benutzt.
Also ist an der Stelle die Datenbank mit den entsprechenden Stundenvorlagen für den Stream, die bessere alternative. Einfach für die Streamadresse einen Eintrag in der DB anlegen und für die Betreffende Zeit in der Stundenvorlage mit einplanen. Dann läuft der Stream über einen der Player, wie ein einzelnes Audio-Element.
Greetz
Malte
Ich darf hier kurz ergänzen (Vorgespräch mit @kh58 jenseits des Forums):
Der Zuspieler wird vermutlich keinen eigenen Stream produzieren, sondern an einen senden. Das heißt, @kh58 wird wohl den Stream stellen müssen - deswegen brachte er den Tester ins Spiel.
Letzteres halte ich für keine so gelungene Idee - da wäre ein dritter Mountpoint vielleicht doch besser?
Man stelle sich vor, da geht einer auf den Tester und dank des Stream-Monitors ist der dann gleich live auf dem produktiven Stream? 
Meine - grobe! - Idee war folgende:
DJ > Encoder > Moderatoren-Icecast beim Sender > Stream-Monitor > produktiver Stream, auf dem sonst die Rotation läuft.
Ist das nicht euer Modell, @shorty.xs?
Ja, wir machen das in etwa so.
Wir haben 2 Icecast Server, die eine gegenseitige Redundanz bilden. Der Einfachheit halber, beschreibe ich hier mal nur einen.
Der Server hat mehrere MountPoints konfiguriert.
- Auslieferung an die Hörer 192k.mp3
- Auslieferung an die Hörer 32k AAC+
- Einspeisepung Automation
- Live-Einsepeisung 1 für unsere Studios
- Live-Einsepeisung 2 für unsere Studios
- einen Teststream
2-6 sind im Serverstatus nicht einsehbar und natürlich auch nicht public.
1-3 werden dauerhaft von meinem mAirlist Server befeuert.
Der 3. Einspeisepunkt Automation ist historisch gewachsen, wird eigentlich nicht benötigt. Den nutze ich nur um gewisse Informationen aus den METAdaten zu extrahieren. Auf dem Redundanzssystem kann ich darüber ein Rahmenprogramm einspeisen, sollte der mAirlistserver mal ausfallen oder einen Neustart brauchen. Ich wollte beide Icecast Server mit exakt identischer Config haben.
Nr 6. der Teststream ist komplett autark und hat mit dem restlichen System nichts zu tun. Der wird bei bedarf eingespeist und auch genau dort wieder abgehört.
Auf den beiden Einspeisepunkten 4 & 5, lauscht mAirlist mit dem Stream Monitor, wobei 5 die höhere Prio hat und 4 übersteuert. Sobald auf einem der beiden Mount Points etwas eingespeist wird, schlägt der Stream Monitor an, unterbricht die Automation und schleift das Signal durch. Fällt das Signal weg, das ganze retour.
Diese Konzept kann man natürlich um quasi beliebig viele Einspeise-Streams erweitern, so kann man den “externen” auch eigene Passwörter geben. Die entsprechenden Stream Monitor auf diesen Einspeisepunkten, würde ich dann aber über Events sperren und einschalten. So dass der nur zum vereinbarten Zeitpunkt funktioniert. Ausserhalb dieser Zeit funktioniert der automatisch auch als Teststream, weil der Stream Monitor nicht darauf reagiert. Wenn man die Adresse kennt, kann man so einen Einspeisepunkt natürlich auch direkt abhören.
Bei uns gibt es zusätzlich noch ein Webinterface in unserem Intranet, wir lassen die Stream Monitore immer aus, wenn sie eigentlich nicht gebraucht werden. Bevor ein Moderator auf Sendung geht, schaltet er den entsprechenden Stream Monitor über das Webinterface ein. Das dient als zusätzliches Sicherheitslevel, sollte mal versehentlich jemand eine Einspeisung starten, z.B. weil er gerade am Studio schraubt. (Ja, alles schon passiert)
Diese Steuerung ist über REST an mAirlist angebunden und Open Source hier verfügbar.
Coole Idee. 
Wie hast du das realisiert?
Ich habe da keine Timer drin, bei uns wird das nur über das Webinterface geschaltet. Der Befehl den ich verwende, lässt sich aber auch zeitgesteuert als Event ausführen.
Jeweils ein kleines mAirlist Script zum einschalten und zum ausschalten. Siehe hier.
2 Likes
Danke für eure Ausführungen. Die beschriebenen Wege sind nachvollziehbar. Wir müssen uns also nur für einen entscheiden und entsprechend umsetzen.
Hi Malte,
gibt’s aktuell Bestrebungen das Tool aufzuschrauben?
Z.B. in Bezug auf das Abgreifen der aktuellen Playlistposition, um das Ausspielen des aktuellen Elements abzuwarten, so daß man den aktuellen Song nicht vor dem normalen Ablauf ausblendet?
Viele Grüße
Michel
Pläne gibt es viele, einzig es mangelt massiv an Zeit. Darum ist das Ding Open Source. Feel free to contribute.
@mEGGs oder siehst Du das anders?
… ja sehe ich auch so. Das Tool entwickeln wir auf jeden Fall noch weiter, allerdings ist dafür aktuell keine Zeit vorhanden. Da wir das Open Source gestellt haben, würde ich mich da sogar freuen wenn das weiterentwickelt wird. Da steckt noch viel Potenzial drin.
Wenn es von uns was neues dazu gibt dann teilen wir das hier gerne …
Hi, ihr beiden, wenn wir jemanden im Team hätten, der das könnte, würden wir sehr gerne Entwicklungen mit übernehmen. Aktuell können wir nicht mehr als Ideen liefern. Tut mir leid.