Stream-Monitor hext rum

Deutsch / German mAirList 6.x
1

Nabend,

wir testen seit einigen Tagen den Stream Monitor (6.x) für folgendes Anliegen:

Jeder DJ soll jederzeit zu “Mairlist” connecten und auch direkt live geschaltet werden.
Dazu hat jeder DJ seinen eigenen Mount Point.

Also wie folgt beim Stream-Monitor eingefügt:
“Zum Überwachen”:
https://streamurl.de/DJ01
https://streamurl.de/DJ02
https://streamurl.de/DJ03
https://streamurl.de/DJ04
…

Dies funktioniert soweit.
Beim “Wenn on Air”:

→ “Steam einfügen” (nicht force “abspielen”):
https://streamurl.de/DJ01
https://streamurl.de/DJ02
https://streamurl.de/DJ03
https://streamurl.de/DJ04
…

Nun ist es jedoch so, dass beim Connect von einem DJ die Dateien/Stream-URLs eingefügt werden, aber eine 50/50 Chance besteht, ob es überhaupt geht.
WENN es geht, dann läuft es, bei einem Disconnect werden jedoch viele weitere normale Lieder in der Playlist danach angespielt und übersprungen, was einen kurzen Hardcore-Kirmes-Modus auslöst (mehrere Lieder gleichzeitig durch den “Übergang”).

Seit heute habe ich “wenn on Air” → “Automation ausschalten”; “wenn off Air” → “Automation starten”. Mal sehen, wir testen immer noch hin und her.

Haben alles versucht:

Statt Stream-URLs m3u Dateien, nix.
Ein Jingle “Forcen” (abspielen, statt einfügen), danach die DJ Streams, nix.
Von Shoutcast 1, Shoutcast 2 und mittlerweile Icecast2 gewechselt für die DJs. Custom Buffer etc. auch versucht (50% "BASS_URL_FILE_NOT_SUPPORTED), weil Puffer wohl “zu wenig”.
Zeiten zum “Prüfen” der Streams erhöht, um den Puffer zu vergrößern
Und was weiß ich noch…

Sind langsam echt am Ende mit den Nerven, theoretisch MÜSSTE es ja klappen.
Wenn ein DJ Stream “übersprungen” wird, der live gegangen ist, hilft nur noch ein manuelles Einfügen (rechts im “Papierkorb”), dann geht es.
Dann kommt nur noch das Problem der Folge-Lieder, die angespielt und dann übersprungen werden (diese sind nicht fehlerhaft).

Vielleicht hat es was damit zu tun, dass auch “offline” Streams eingefügt werden? Aber diese müsste doch direkt “gekickt” werden, weil 404?
Jedoch muss jeder DJ seinen Mount haben, also alles über eine Master-URL ist aktuell nicht möglich (deshalb auch das einfügen aller Mountpoints). :confused:

Hat jemand eine Idee, woran wir scheitern?
Vielen Dank im Voraus! <3

Nachtrag: Achso die Streams der DJs laufen auf MP3@192kbps

2

Nutzt ihr denn den High Priority Input?

Sinn des Stream-Monitors ist es zwar zunächst, die ankommende URL zu überwachen.

Wird dort ein Signal erkannt, wird der erkannte Stream von mAirlist an das in der Audiokonfiguration festgelegte Ziel gesendet.

Je nach Priorität kann ein weiterer Stream diesen Stream übertrumpfen und der mAirlist-Encoder spielt sofort den Stream mit der höchsten Prio und fadet den vorigen aus.

Soviel zum grundsätzlichen Betrieb.

Wenn ihr nun eine URL in den Stream-Monitor eintragt und dann bei „wenn On-Air“ die selbe Streamadresse nach dem Erkennen des Streams noch mal in die Playliste eintragen lasst, ist das nicht nur doppelt gemoppelt, sondern produziert folgendes Szenario, wenn der Stream-Monitor auf den Encoder oder einen Kanal des Mischpults geroutet ist, auf dem die PL läuft:

  • Stream-Monitor erkennt URL und spielt sie
  • Playliste spielt Stream-URL ebenfalls, ggfs mit Jingle davor
  • Stream läuft also doppelt und zeitversetzt → Kirmes :sunglasses:

Lösung: Stream-Monitor auf High Priority Input (HPI) routen.

Sobald dann ein Stream erkannt wird, leitet mAirlist diesen zum High Prority-Input weiter.

Der Encoder erkennt den HPI und FADET die Playliste komplett aus, selbst wenn sie im Hintergrund weiterläuft, während der Stream direkt zum Encoder geht und von dort gesendet wird.

Wenn eure DJ-Streams gleichwertige Prioritäten haben, verbindet mAirlist den nächstfolgenden aktiven Stream von oben nach unten, sobald der andere Stream als off-air erkannt wird.

3

Hi,

danke für die schnelle Rückmeldung! :slight_smile:

Also reicht es, die “zu überwachenden URLs” einzugeben? Und nichts bei “Wenn on Air…”?
Über Mairlist wird nichts gestreamt, dort wird nur das Master Signal zu einem HW Kompressor geleitet und dieser streamt es an die Main-ICY.

Im Prinzip soll nur ein DJ/Mod dafür sorgen, wenn dieser mit seinem Mountpoint online geht, die Playlist automatisch zu “stoppen” und dann der Livestream regulär “in der Playlist” läuft, bis dieser offline geht. Danach die Playlist wieder. Oder währenddessen “stumm” die Playlist rennt, solange der Livestream “aktiv” bleibt, bis offline.
Oder wenn ein 2. online geht, dass dieser den 1. kickt (als “Übergang”, kommt aber selten vor = gleiche Prio für alle).

1 Like
4

Genau darum geht’s. Die Playliste läuft im Hintergrund stumm weiter während ein DJ live über den High Priority Eingang am Stream Monitor an kommt und übertragen wird.

  • Was ist ein Main-ICY? (Ich lerne gerne dazu :wink:)
  • Mit was geht das Signal letztendlich an die Hörer?

Der Streammonitor ist vorraning dazu gedacht, den internen Encoder von mAirlist zu “beliefern” und das aktuell laufende Playout in den Hintergrund zu stellen. Encodiert oder verbreitet ihr das Signal nun mit anderen Mitteln könnte es interessant werden.

5

Nein :wink:, denn…

Der Begriff Encoder hat nicht primär etwas mit dem Streamen zu tun. Der Encoder ist quasi der Punkt, an dem zunächst alle Audiosignale von mAirlist gesammelt und von dort als Master-Out entweder als Stream oder an Hardware-Lösungen weitergeben werden.

Zitat:

The encoder combines these signals into a master signal and sends it to the Icecast/Shoutcast servers. Additionally, the master signal is sent to the “Encoder Playback” audio device set up in the configuration if you want to listen to it locally.

TLDR;

Audio Routing

The audio output for the Stream Monitor is set on the Audio Devices page in the config app or Control Panel. You can route the output to any soundcard or the encoder.

The Stream Monitor works best when running on an automated system where the automation is playing directly into the encoder, not any physical sound card. In that case, you can use the Encoder High-Priority Input. Set up your audio routing as follows:

  • Player/Cartwall output: “Encoder” (primary or secondary)

  • Stream Monitor output: “Encoder - High Priority”

The High Priority input will mute the regular encoder input as soon as any audio item is sending data to it. So your automated playlist will continue to play in the background, but it is automatically muted as long as the Stream Monitor is rebroadcasting any stream. When the stream ends, the encoder input will be unmuted again. Logging will also be disabled while the input is muted.

Das

ist also auch machbar, wenn ihr vom Encoder ein Signal über eine Sound-Karte oder ein anderes Audio-Routing zur Hardware einsetzt.

Ich habe das inzwischen so bei einigen Radios eingerichtet, die ein 24/7-Programm auf einem Windows-Server laufen lassen und ihre Remote-DJs dann per Stream-Monitor auf diese Weise einbinden.

Der Vorteil einer im Hintergrund weiterlaufenden Playliste: Bricht mal ein Zuführstream eines DJ ab, wird einfach übergeblendet, statt dass Stille herrscht. Auch das Kommando “Playlist stoppen wenn on-air” und “neu starten” sobald der Stream wegfällt kann euch in Teufels Küche bringen, falls ihr viel mit Fixzeiten arbeitet und mAirlist in der Automation zu denen springen bzw. auf sie warten soll. Besonder dann, wenn der DJ nur wenige Sekunden seine Verbindung verloren hat.

empfehle ich aus persönlicher Erfahrung deshalb nicht.

Der High Priority Input ist schon eine ziemlich coole Einrichtung und blendet die Playliste schnell und einfach aus, während sie im Hintergrund weiterläuft… :slight_smile:

Übrigens musste ich nach Aktivierung des HPI erstmal mAirlist neu starten, damit die Playliste ausgefadet wurde - sollte das also nicht gleich funktionieren, bitte erstmal nach Änderung der Config euer mAirlist neu starten…

Bei Fragen melde dich gerne wieder!

6

Seid ihr inzwischen weitergekommen?

…undeinwenigtext…

7

Hi,

sorry für die späte Rückmeldung.
Noch lief es nicht, aber die “Wiedergabe” wurde nicht übernommen.
Jetzt mal neugestartet und mal schauen ob es nachher funktioniert.

image

Dies ist die gleiche SW-Weiterschleifung wie bei der “Standard-Wiedergabe” für alles (Master-Out und Playlist).

Ist so richtig, oder? Das sollte dann ja ab sofort den Playlist-Output “übertönen”?

Anbei kurz die Frage: Werden die Titel-Updates der Mods und DJs auch übertragen? Oder müsste ich dafür nen kleines Programm schreiben (aktuell schreibt Mairlist die Titel-Updates in eine TXT Datei, diese wird von einem anderen Programm aufgegriffen und weitergeschleift, aus Gründen).

Liebe Grüße! :slight_smile:

8

NEIN!!!

Das Ausfaden passiert im Encoder, mit eurer Einstellung sendest Du nur ein zweites Signal am Encoder vorbei direkt zur Output-Soundkarte…

Da kann der Encoder nix ausfaden.

Lies bitte meine ausführliche Erklärung dazu noch einmal mal durch.

Besonders wichtig dieser Part:

Der Stream-Monitor muss also zum High Priority Input des Encoders geroutet sein, nur dann funktioniert es.

Alle anderen Einstellungen lasst ihr gleich, da das Master Out-Signal dann ja vom Encoder kommt, wo der Stream reinläuft und die Automation ausgefadet wurde.

Wenn das Signal über den Encoder läuft, auf jeden Fall. Im Encoder erfolgt der Abgriff aus dem Stream und wird an weitere Streams weitergegeben, wenn aktiviert.

Ob das mit eurem Script funktioniert, kann ich nicht sagen :wink:

9

Hi,

ah ok.
Hier der ganze Auszug, als Kontroll-Instanz - also so? :grimacing:
image

10

Falls ihr dann direkt von mAirlist aus den Stream sendet, ja. :blush:

Aber: Du schriebst was von externem HW Soundprocessing - wie habt ihr das Routing konfiguriert?

Nach dem Screenshot kommt das Signal über das virtuelle Kabel in den Encoder zurück. Richtig?

Ich frage, weil in diesem Setup eventuell/vermutlich das Signal des ankommenden Streams nicht durch euren HW-Prozessor läuft und somit keinen Limiter, Compressor whatever durchläuft, was ja für einen durchgehenden gleichen Klang zwischen Automation und Streams gut wäre… :sunglasses:

11

Ja, war mir nicht sicher.
Bin nur vorsichtig und möchte diese “Endlosschleife” (Eingang → Ausgang → Eingang …) verhindern.

Im Prinzip ist “Line 1” der Eingang (da soll Mairlist alles hinballern), der “Output” ist wie dort beschrieben eine bereits vorgearbeitete SW-Normalisierung, was dann “raus” geht als finales Signal für externen Encoder oder HW.
Deshalb ist als Wiedergabegerät keins ausgewählt, da würde sich dann die Endlosschleife von In-Out-In-Out… beißen.

Wenn beim Line-Eingang (Encoder) nun Line 1 ausgewählt wird (statt die WASAPI wie jetzt), was dann auf Line geschleift (und gefiltert) wird für den ext. Ausgang, ginge das? Theoretisch sollte es ja, bin halt nur vorsichtig, sonst gibt es richtig Party, die dann alle laufen lässt. :smiley:

12

Puh, das müsste bei euch so passen. Schicke mir sonst gerne hier per PM mal deine komplette Audiokonfiguration/Routing als Screenshot :wink:

13

Ach… Wir testen es die Nacht einmal, wenn weniger los ist.
Haben das “Problem” ja schon seit einiger Zeit, also kommt auf den Tag nicht an. Kann ja berichten, was die finale “Lösung” ist, wenn jemand das selbe Problem hat. :innocent:

Aber danke schon mal für die ausführliche Anleitung/Hilfe. :smiling_face:

1 Like
14

Nabend,

zur späten Stunde mal ein Update.
Ne, leider immer noch nicht - es passiert nichts. Mairlist fügt auch keinen Stream in die Playlist.

Aktuell habe ich es so probiert, wodurch wir schon mal einen Schritt voraus sind.
image

image

image

Also folgendes: Erkennt Mairlist einen Stream, geht der Encoder auf den SW-Input (Line 1), wie Playlist. Damit kein Kirmes: Einfach beide Player schön ausfaden (je nach dem welcher an ist), Automation stoppen und deaktivieren. Stream off: Automation wieder an und kommendes Lied anfangen.
Das stoppt zwar die Playlist, aber immerhin funktioniert es so automatisiert schon mal.

Wenn ich etwas beim Encoder zu den Eingängen schalte: Nichts.
Wenn ich nur den Output (Line 1) schalte, spielt Mairlist beides ab (Playlist + Stream).
Der Stream läuft auch “unsichtbar” im Hintergrund. Deshalb der Automations- und die Player-Stops.

Kann auch sein, dass ich damit das Chaos of Doom ausgelöst habe. :exploding_head:
Aber nach einigen Tests (Connect/Disconnect) lief es wie fast gewünscht.
Muss dann noch ne SW schreiben für die Titelübergabe sonst.

Achso, Mairlist bei den Änderungen auch immer neu gestartet.

15

Zwei Anmerkungen dazu:

  1. Bei “Wenn on air” ist der FADEOUT der beiden Player nicht notwendig. Durch AUTOMATION 1 STOP wird der Automations-Player ohnehin ausgefadet.
    Du kannst das manuell gerne mal nachstellen.

  2. Du kannst die Fade-Time für den High-Priority-Player, also die Überblendung, im Encoder unter “Optionen” einstellen.

Nicht notwendig. Alles, was du in der Systemsteuerung einstellen kannst, wirkt sich unmittelbar auf das Playout aus. In dem Fall musst du mAirList nicht neu starten.

Das nur am Rande.

16

Hi,

danke für die Rückmeldung.
Zu 1.)
Als “nur AUTOMATION 1 STOP” ausgewählt war, lief das Lied in der PL noch zu Ende und gab einen schrecklichen Übergang. Deshalb zusätzlich das FADEOUT.
Weiß nicht, wieso das bei uns gefühlt anders ist. :face_with_spiral_eyes:

2.) Ist eingestellt auf 5 Sekunden.

Aber dachte ein Neustart sollte besser sein aus den vorherigen Antworten. Hat ja nicht geschadet, wenn man es im Tief (Nachts) mal fix macht. Und einmal war Mairlist durchgehend bei 100% Last, als ich das Device im ENCODER geändert hatte. Kurios.

Liebe Grüße! :slight_smile:

17

Wie aus einer Randbemerkung eine mögliche Fehlerursache werden kann… :face_with_raised_eyebrow:

Na hoppla! Wie das denn? :flushed:
Also… ich habe das mal im normalen Automationsbetrieb nachgestellt, ohne Stream Monitor.
Bei AUTOMATION 1 OFF kann ich das nachvollziehen. Klar, da wird nur der Automations-Modus selbst ausgeschaltet, aber der Titel läuft weiter.
Wenn du hingegen AUTOMATION 1 STOP verwendest, geht der aktuelle Player sofort in den Playerstate FADE.

Noch eine Randbemerkung: Du musst nicht den Modus “Befehl ausführen” nutzen, wenn die Funktion selbst zur Verfügung steht:
Automation > Automations-Wiedergabe anhalten
Bei “Automation ausschalten” hast du es ja scheinbar auch gemacht. :wink:

Du meinst die High-Priority-Fade-Länge (ms), die auf 5000 steht, korrekt?

Und trotzdem…

Kannst du das “schrecklich” bitte näher beschreiben?

Moment, langsam, zum mitdenken:
Welches Device im Encoder hast du wie geändert? Ich stehe gerade auf dem Schlauch.

18

Naja, ist wie im Screenshot und durch das FADEOUT geht es aktuell.
Aber ich teste mich weiter rum. :smiley:

Der “schreckliche” Übergang = Weil Stream + Song gleichzeitig, bis Playlist-Song zu Ende war.

Und die 100% Last kamen, als ich den Encoder auf HPI (und später auf “deaktiviert”) gestellt hatte. Nach einem Neustart von Mairlist ging es wieder und die Settings waren übernommen. Deshalb hatte ich aus Vorsicht auch danach bei Einstellungswechsel Mairlist neugestartet (zumindest bei den Devices).