Liveschalte + GUI Element Idee

Stefan_Hillen · May 24, 2026, 10:24pm

Mein Tipp ist ein ganz anderer Ansatz, den ich mit einigen Radiokunden inzwischen verfolge: Den Icecast-Server auf dem selben Server installieren, auf dem mAirList läuft.

Dann über

http://localhost:8000/<mountname>

einbinden in den Stream-Monitor, was den Umweg samt Zeitverlust über “das Internet” schon mal eliminiert. Jeder Moderator hat dabei seinen eigenen Mountpoint.

Die Verzögerung zwischen Icecast und mAirList ist miniminimal, auch das Signal der Moderatoren ist richtig schnell live, weil es nicht erst über mehrere Ecken zugespielt wird.

Dann den Stream im Stream-Monitor entweder per Event freischalten.

Für das nun folgende ODER habe ich über die vergangenen Monate etwas gebastelt, das gestern bei mir nach den ersten Ideen im Oktober nun einen stabilen Status erlangt hat und nach jetzigen Planungen bald verfügbar sein wird: Mein REST-Monitor mit schaltbaren Streams direkt aus dem Browserfenster.

Name: OnAirPanel

Je nach Benutzerrolle mit

read-only (nur Playliste auf dem Server und Stream-Kontrollplayer sehen)
Moderator (darf zusätzlich Status von IceCast und Streammonitor sehen)
Moderator+ (darf zusätzlich Streammonitor aktiv on-air schalten)
Technik/Administrator (darf und kann zusätzlich Playliste direkt in der Webansicht verändern, Encoder trennen/verbinden, Automation / Assist / nächstes Lied oder Start/Stop abfahren)

Das richtet sich an Radios mit genau diesem Setting - mehrere Moderatoren/Studios weit verteilt. Mehrere Vertrauensstufen, damit niemand was kaputt macht und vor allem KEINER auf den Server kommen muss, der nicht absolute Ahnung hat was er da klickt.

Moderatoren müssen nur den Monitor auf dem Smartphone oder Senderechner laufen lassen, sich mit Icecast verbinden, sehen dass die Verbindung steht, dann ein Klick und sind direkt “on air”. Und mit dem Icecast-Server auf dem Server ist der Versatz wirklich gering.

Der Versatz ist so minimal, dass ich sogar nach einem Lied, dessen Ende man per REST mit knapp einer halben Sekunde Versatz sieht, online gehen kann und mein mAirList im Studio zuhause so nahtlos verbindet, dass es für den Hörer fast nicht zu bemerken ist. (Streammonitor wird in mAirList dabei jede Sekunde abgefragt).

Einziges Manko: Den Moderatoren zu erklären, dass sie NICHT auf den Stream von Alexa oder des Players auf der Webseite des Radios hören, sondern sich rein am OnAirPanel orientieren müssen, da das auf Sekunden genau die Playliste zeigt.

Um das ganze dann auch richtig zu machen, habe ich im Setup-Bereich noch eingebaut, dass man eine korrekte icecast.xml exportieren, aber auch eine bestehende importieren kann, die Wetterdaten für bis zu 24 Kacheln selbst anlegen kann, die Playlistenanzeige nach eigenen Bedürfnissen gestalten kann, das nötige Hintergrundscript für mAirList herunterladen oder auch eine xml für den Stream-Monitor mit den einzelnen Streams direkt exportieren und in mAirList wieder importieren kann.

Mehr Infos dann, wenn das OnAirPanel verfügbar ist…

onairmitflo · May 24, 2026, 10:35pm

Genau das mache ich bereits. Es kommt aber auf die Config von Icecast2 an. Umso höher der Buffer, umso länger/größer das Delay. Ergo: so stabiler ist der Stream auch gegenüber Dropouts/Paketverluste im Internet. Aber du kannst mir gerne wenn du möchtest die Settings dafür aus deiner Icecast2 Config zukommen lassen, dann kann ich das ja mal testen. Mit der Standardconfig habe ich folgende Werte:

<limits>
    <clients>100</clients>
    <sources>4</sources>
    <queue-size>524288</queue-size>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>10</source-timeout>
    <!-- If enabled, this will provide a burst of data when a client 
         first connects, thereby significantly reducing the startup 
         time for listeners that do substantial buffering. However,
         it also significantly increases latency between the source
         client and listening client.  For low-latency setups, you
         might want to disable this. -->
    <burst-on-connect>1</burst-on-connect>
    <!-- same as burst-on-connect, but this allows for being more
         specific on how much to burst. Most people won't need to
         change from the default 64k. Applies to all mountpoints  -->
    <burst-size>65535</burst-size>
</limits>

Mit deinem Dashboard bin ich vorsichtig, denn ich möchte unter keinen Umständen eine Schnittstelle zu mAirList ins Internet bringen. Der Icecast2 Stream liegt bei uns in einem VPN, hier wäre rein Theoretisch auch ein Dashboard möglich. Aber bevor ich darin Stunden investiere der KI zu sagen wie ich was haben will (ohne dass ich Ahnung hätte was die KI programmiert), gebe ich den Moderatoren einfach ein Low-Latency Audio Signal und eine Bildschirmanwendungsübertragung wo man nur Zuschauerrechte hat.

PS: aber die Ansätze von dir find ich gut! Wieviel KI (Claude Code) hast du da verwendet?

Stefan_Hillen · May 25, 2026, 12:08pm

Moin Flo,

die Zulieferung wandert bei euch also auch intern über localhost direkt zu mAirList weiter. Sehr gut!

Eure Konfiguration ist trotzdem eher wie für normale Hörer-Clients dimensioniert, nicht für einen lokalen mAirList-Streammonitor.

<limits>
    <clients>10</clients>
    <sources>4</sources>
    <queue-size>131072</queue-size>
    <client-timeout>30</client-timeout>
    <header-timeout>15</header-timeout>
    <source-timeout>15</source-timeout>
    <burst-size>0</burst-size>
</limits>

Etwas konservativer, falls ihr Moderatoren mit schlechterer Leitung habt (also unter 16.000er DSL)

    <queue-size>262144</queue-size>

Beide Einstellungen sind völlig ausreichend und dürften eure Latenzen stark verkürzen.

Im Setup ist Cloudflare als Möglichkeit bereits vorgesehen. Das ist kostenlos und schnell auf einer eigenen Domain eingerichtet, die 5 Euro im Jahr kostet (die Anleitung steht sogar im Setup des Panels als Hilfe dabei )

Cloudflare kommuniziert dann im Grunde wie über ein VPN und man kann sogar den Standard-Port für Rest (9300) auf dem mAirList-Server schließen.

Als weitere Sicherheit habe ich einen Reverse Proxy eingebaut, so dass auch niemals sensible Daten exponiert werden.

RadioFoxandMore · May 26, 2026, 7:47pm

Also wir nutzen auch einen extra Icecast Server auf dem mAirlist Windows Server. Also auch ähnlicher Ansatz mit geringer Latenz.

Wir nutzen einfach nur den Streammonitor mit einem Fading von 3 Sekunden. Es passt super, wenn jemand auf Sendung geht: Einfach 3 Sekunden warten und es klingt sehr sauber.

Ich sehe aber schon interessante Ansätze, bin aber auch eher zurückhaltend bei Weblösungen (auch wenn sie hier schon mit der Rechtevergabe durchdacht ist).

shorty.xs · May 27, 2026, 7:02am

Das ist ein absolutes Muss. Ich würde heute niemals mehr einen Dienst der auf einer Windows Maschine läuft, einfach so per port forwarding ins Internet freigeben. Da gehört immmer ein Reversproxy mit Fail2Ban davor.

In meinen Setups würde ich noch nicht einmal den Icecast direkt auf dem mAirlist betreiben aber vielleicht habe ich einfach in meiner Arbeit einfach zu viele Hacker Angriffe auf Windows gesehen.

RadioFoxandMore · June 4, 2026, 9:57am

Da ich ja aktuell auch viel bastle und mein Dashboard auch in der ersten Version fertig ist, hier vielleicht noch ein Ansatz.

Wir nutzen für unsere Webseite Wordpress und ich habe da auch ein Dashboard für unsere Team erstellt. Ebenfalls mit Rechtevergabe. Hier ist aktuell aber keine Steuerung von mAirlist geplant, sondern eher eine bessere Übersicht von Daten an einem Ort zu schaffen. Aber natürlich werden hier auch die Daten von mAirlist angezeigt.

Die gewünsten Daten von mAirlist, Icecast-Servern (einer auf dem mAirlist-Server und einer zum Verteilen des Streams aus mAirlist) werden über ein Powershell-Skript gesammelt (läuft auch auf dem mAirlist-Server) und dann per Push an Wordpress gesendet. Dies geschieht aktuell alle 5 Sekunden. Somit kann ich hier die aktuell gespielten Titel, aktuelle Playlist (mit Timing-Skips usw.) und die geplante Playlist der nächsten Stunde aus der Datenbank anzeigen. Somit bliebe ein Zeitfenster von 5 Sekunden (welches das Dashboard glättet) und die normale Latenz des Internets und des mAirlist-Icecast-Servers.

Für deinen Ansatz mit geplanter “Sendung” sollte dies eigentlich genügen. Eine durchschnittlich tatsächliche Verzögerung, könnte man mit einrechnen.

Gruße, Heiko

Liam · June 4, 2026, 10:56am

Ziemlich viel Traffic in kurzer Zeit.
Würde hier nicht alle 25-30 Sekunden reichen?

RadioFoxandMore · June 4, 2026, 11:04am

Ja, man kann die Daten natürlich auch in größeren Abständen senden. Aber dann würde bei Abweichungen natürlich auch später korrigiert.

ssnoopy · June 8, 2026, 3:11pm

Zum Beispiel einfach nur wenn ein neuer Titel anfängt…

RadioFoxandMore · June 8, 2026, 4:04pm

Würde das System weniger belasten, korrekt.

Aber aus Erfahrung kann ich nur sagen, das Timer im Browser nicht sehr präzise sind. Zudem werden ja mittlerweile Browserfenster auch gerne mal in den Standby geschickt.

30 Sekunden funktionieren hier aktuell sehr gut und belasten den Server nicht zu sehr. Wir nutzen hier auch nur einen vServer und das klappt bisher ohne jegliche Probleme.

UliNobbe · June 8, 2026, 7:09pm

Hm.
Zwei Punkte mit Rückfragen:

Definiere bitte “nicht sehr präzise”.
Über welche Größenordnung reden wir hier bitte?
Und: Betrifft das nur den Browser oder auch andere Bildschirmobjekte mit Zeitanzeige?
Standby:
Das passiert eigentlich nur, wenn die Systemlast so hoch ist, dass der Ausspielung Vorrang vor der GUI gegeben wird. Aber das konnte ich im Regelbetrieb bislang nicht feststellen.
Hast du das schon mal überprüft? Wie oft passiert dieses “mittlerweile” und seit wann?

RadioFoxandMore · June 8, 2026, 7:21pm

Hallo, Uli.

Ich glaube man muss hier immer zugrunde legen, das es um Browseranzeigen geht. Hier wurden immer strengere regeln festgelegt, was man darf und was nicht. Das durch Missbrauch, garantiert auch zu recht.

Eventuell kannst du dich an unseren Sendungsanzeige erinnern, die eigentlich die genaue Restzeit der Sendung anzeigen sollte. Irgendwann sind es Sekunden oder gar Minuten.
Nein, soweit mir bekannt und rescherschierbar, alle Browserfenster aktueller Browser. Das passiert sogar schon, wenn ein Tab gewechselt wird. Es finden sich Optionen wie Seite immer aktiv lassen, teils aber in den Developer-Menüs

Lieben Gruß, Heiko

UliNobbe · June 8, 2026, 11:36pm

Ah, Moment - Browser = Internet-Browser, hat also nichts mit dem mAirList-Browser zu tun (der ja auch eine Uhr abbilden kann).
Klassisches Mistverständnis.

Ich war komplett im mAirList-Bezug und habe mich auf alle Eventualitäten innerhalb der mAirList-GUI eingeschossen.

Meinst du jetzt aus Sicht des Moderators (ich war ja mal einer davon)? Nicht, dass ich mich erinnern würde. Ist ja nun auch schon ein paar Tage her.
Da hätte ich ohnehin nicht draufgeschaut. Ich backtime mit mAirList und ein wenig rhetorischem Geschick pünktlich auf TOTH (“Modis” hassen das ).
Als Hörer? Keine Ahnung.
Um ehrlich zu sein, das interessiert mich auch nicht. Ist das so eine Art Countdown bis zum Sendungsende, angezeigt auf der Homepage? Kann eigentlich nur Vorproduktionen betreffen oder sich exakt an den Sendeplan halten.
Entweder verstehe ich dich gerade massiv falsch, oder ich erkenne keinen Mehrwert darin.

Wie auch immer, dieser Teil der Diskussion hat meiner Meinung nach keinen direkten mAirList-Bezug (bitte korrigiere mich, wenn ich falsch liege) und damit endet mein Gastspiel in diesem Thread vorerst.

onairmitflo · June 9, 2026, 9:25am

Ich habe mich diesbezüglich für das mAirList Studio Monitor Script entschieden. Es liefert genau die Infos an ein Frontend welches ich in diesem Anwendungszweck benötige.

Ich werde das Frontend dementsprechend so umprogrammieren, dass es zwei Versionen gibt:

Wie der Studio Monitor ja von grund auf schon ist, nur mit mehr Elemente “als Vorschau”, sodass Moderatoren sehen, wann zB. ein Stream Element geplant ist und zu welcher echten Startzeit dieser geplant ist.
Einfach nur einen Countdown, nicht mehr und nicht weniger. Wenn ein Stream Element in der Playlist geplant ist, und in der Vorschau von 1. erscheint, fängt dieser Countdown an runterzuzählen. Abzüglich meine ca. 2s Latenz. Diesen Countdown kann bei jedem mAirList Client als GUI Objekt “Browser” super einfach eingebunden werden, und der Moderator muss nur ungefähr rechtzeitig auf Play drücken

War für mich die simpelste Lösung um das Programm auch bei einer Umschaltung zu einer Livesendung weiterhin fließend zu gestalten.

Hierbei wäre ich komplett weg von der “Stream Monitor” Lösung. Demnächst werden wir einfach ein Stream Element in der Automationsplaylist verwenden, welches uns noch weitere Probleme löst

Was sagt ihr dazu?

Liebe Grüße

Radioman0410 · June 14, 2026, 9:43am

Ich habe das in der Praxis einmal folgendermaßen gelöst:

mAirList A lief im 24/7-Betrieb und spielte dauerhaft das reguläre Programm. Wenn sich nun ein Studio von außen zugeschaltet hat, wurde nach dem Service (Verkehr/Wetter) per REST und einem Element “Befehl” ein Trigger am externen Sendestudio ausgelöst. Dieser Trigger startete im externen Sendestudio in mAirList den Player 3. Es wurde im 24/7-Playout der externe Stream über ein entsprechendes Element, also den Livestream, übernommen.

Player 3 spielte ein kurzes Übergabeelement, zum Beispiel einen Jingle. Dadurch war für den Moderator eindeutig klar: Jetzt geht es los. Die 3-4 Sekunden Latenz vom Icecast sind hier zu vernachlässigen, der Übergang war trotzdem sehr sauber. Player 3 war nicht zu editieren, es gab lediglich für den Moderator den Fortschrittbalken zu sehen.

Den Stream Monitor habe ich aus den genannten Gründen nicht verwendet, da die Übergabe damit in diesem Fall schwieriger und weniger eindeutig gewesen wäre. Die Kombination aus REST-Trigger, “unsichtbarem Player” und Übergabeelement war für uns deutlich kontrollierter und sauberer.