wir testen gerade den Stream-Monitor der seit der 5.1. Version draussen ist.
Leider haben wir das Problem, dass wenn die eingebundenen Streams offline sind, dies von Mairlist sehr oft nicht erkannt wird.
Die Streams selber sind dabei jedoch immer offline.
Erst wenn ich manuell die Streams einmal auf disable und dann wieder enable setze, hat auch Mairlist erkannt, dass der Stream offline ist.
Im umgekehrten Fall funktioniert es wunderbar, soweit der eingebundene Stream online geht, wird dieser auch sofort abgespielt.
Bloss mit den Offline gehen scheint Mairlist das nicht korrekt umzusetzen.
Kennt jemand von euch das Problem? Und noch besser die passende Lösung dazu?
Was passiert, wenn du den Stream als “Stream (unendlich)” in der Playlist abspielst? Meldet das Element dann korrekt EOF, wenn der Moderator offline geht?
Ich habe die meiste Zeit mit Icecast getestet. Vielleicht verhält sich Shoutcast anders? Müsste ich ausprobieren.
Nenne mir bitte noch die neue Version von Shoutcast, die ihr im Einsatz habt.
Wir haben das gerade nochmal getestet. Stream wurde unendlich eingebunden.
Wenn der Stream offline geht, wird im Mairlist der Ton nur leiser bis zur stille. Eine Anzeige “EOF” wird nicht angezeigt.
Der Stream wird ausgefadet.
Genutzt wird: SHOUTcast Server Version 1.9.8/Linux.
Kann es sein, dass es sich dabei um ein Shoutcast-Feature handelt, so dass dem Hörer Stille geschickt wird, bis sich der nächste Moderator verbindet?
Das ist bei den Shoutcast-Servern nicht eingestellt.
Wenn der Moderator vom Stream runter geht, ist dieser sofort als “Server is currently down.” gelistet.
Die entscheidende Frage ist ja, wie er die bestehenden Hörer-Verbindungen behandelt. Ob er die sofort unterbricht, oder noch aufrecht erhält, vielleicht sogar Stille schickt… Ich bin da echt zuwenig Shoutcast-Experte.
Schick mir doch bitte mal eure Shoutcast-Konfigurationsdatei (sc_serv.conf oder so?) an info@mairlist.com, gerne mit rausgelöschten Kennwörtern. Dann versuche ich das bei mir zu reproduzieren. Kann aber ein paar Tage dauern.
Ich schicke die Datei im Laufe des Tages wenn ich wieder im Home-Office bin.
Und ist kein Problem, wenn es ein wenig dauert.
Wenn wir am Ende die Lösung schaffen, ist es das beste was passieren kann.
Guten Morgen, ich experimentiere auch gerade mit dem Stream Monitor und habe ein ähnliches Problem. Ich bin mir aber nicht sicher ob es an der Programmierung liegt. Die Moderatoren senden ihr Signal an einen Moderatoren-Icecastserver der an den Streammonitor sendet. Das Aufschalten läuft einwandfrei. Eingestellt habe ich: Wenn On Air: Stream abspielen, Automations Wiedergabe anhalten, Automation ausschalten; Wenn Off Air: Automation einschalten, Automations Wiedergabe starten, Datenbank Playlist einfügen Überprüfungsntervall 2 sec. Ziel, dass MAirlist beim nächsten Element bei dem es in der im Hintergrund hinterlegten Playlist angekommen ist startet.
Das Problem: Beim Abschalten des Encoders auf Moderatorenseite passiert folgendes: Streamsignal faded MAirlist aus, es erscheint EOF und dann eine Fehlermeldung bass. … im Player der Streams. Im Streammonitor springt die Anzeige On/Off-air ständig von grün auf rot. Das gleiche mit der Anzeige unter den Playern. Nach ca. 40 Sekunden startet dann die Automation.
Ich konnte jetzt mal den Stream-Monitor mit Shoutcast testen, mit der von RedaktionRC24 bereitgestellten Config.
Wie vermutet, gibt es eine Einstellung, die den Server anweist, die Hörer-Verbindungen offen zu halten (Stille oder alte Daten (?) zu senden), wenn der Source getrennt ist:
; AutoDumpUsers controls whether listeners are disconnected if the source
; stream disconnects. The default is 0.
AutoDumpUsers=0
Als ich diesen Wert auf 1 gestellt habe, hat es bei mir problemlos geklappt. Sobald ich mit dem Source vom Stream gehe, schaltet der Stream-Monitor wieder auf offline.
Allerdings:
Wenn ich den Source dann neu verbinde, geht der Stream-Monitor zwar sofort wieder online - ich höre aber zunächst noch die letzten 10 (?) Sekunden des vorherigen Durchgangs, bevor dann das neue Signal gestreamt wird.
Der Shoutcast-Server hat offenbar irgendeinen zusätzlichen Puffer, der mit den Daten der letzten Source-Verbindung gefüllt wird, und der dann zunächst an den Hörer übermittelt wird, bevor die Daten vom neuen Source übermittelt werden.
Das ist für unsere Anwendung natürlich tödlich, wenn man jedesmal noch das Ende der vorherigen Sendung (letzter Moderator) hört, bevor die neue beginnt. Ich habe keine Ahnung, ob sich das Verhalten irgendwie per Konfigurationseinstellung von Shoutcast beeinflussen lässt.
Alles in allem habe ich den Eindruck, dass Icecast die bessere Wahl fĂĽr den Moderatoren-Server ist.
Wir haben das mal eingestellt und siehe da schon klappt das mit On und Off gehen. Wir haben auch das mit den 10 Sekunden nachpuffern, konnte aber in Netz nichts gescheites zu dieser Thema finden. Was jetzt unser GlĂĽck ist, dass dieses nachpuffern fĂĽr unser Vorhaben nicht von relevanz ist.
Was jetzt auf gefallen ist, wir haben 2 Streams im Streammonitor eingetragen, ein Master (Prio1)- und ein Backupstream (Prio2).
Wenn der Backupstream offline geht, kommt folgende Meldung: "Fehler beim Verbinden mit http://streamadresse nach 22246 Millisekunden: BASS_StreamCreateURL: unsupported file format (BASS error 41). Wenn der Masterstream dann auch offline geht, werden beide als Offline angezeigt.
Stellen wir den Fall umgekehrt nach, zeigt der Masterstream diese Meldung nicht an.
Was mich jetzt stutzig macht, weil ja beide Stream 1zu1 gleich konfiguriert worden sind.
Es wird uns nicht behindern in der täglichen Arbeit, jedoch es verwundert ein wenig. (aber “Wunder gibt es immer wieder…”)
Danke fürs Prüfen, Torben… vielen vielen Dank.
ich habe das oben beschriebene Problem immer noch und bekomme es einfach nicht weg. Es handelt sich um einen vorgeschalteten Icecastserver fĂĽr die Moderatoren. Habe ich evtl. etwas falsch eingestellt im Stream Monitor s.o.?
Ich verstehe nicht, warum im Player was von “can’t open the file” steht. Welches Element ist denn überhaupt darin geladen? Mit dem Stream-Monitor hat das doch zunächst nichts zu tun?
Was den dauernden Wechsel zwischen grün/rot angeht, den du beschreibst, so wäre es super, wenn du mir mal deine streammonitor.ini schicken würdest - und idealerweise die Zugangsdaten für deinen Moderatoren-Server.
Ich kann dir im Gegenzug mal die Daten fĂĽr meinen Icecast-Server geben, den ich immer zum Testen verwende. Wenn du den dann einmal ausprobieren wĂĽrdest, dann wissen wir, ob es am Server oder an den mAirList-Einstellungen liegt.
Danke fĂĽr die Daten. Ich habe es mit deinem Server probiert, hat ohne Probleme funktioniert.
Vielleicht sollten wir zunächst mal klären, was dieses Stream-Element da bei dir im Player macht. Warum liegt das da drin? Warum ist es in der Playlist?
Vielleicht ein Missverständnis? Zur Nutzung des Stream-Monitors ist es nicht notwendig, die Streams in die Playlist einzuplanen.
ich weiss ;). In die Playlist habe ich es nicht eingeplant. Es ist auch nicht aktiv beabsichtigt, aber wenn der Moderatorenserver on Air ist wird das in einem Player angezeigt, der jeweils reingefaded wird. Vielleicht habe ich ja in der Einstellung im Streammonitor irgendetwas falsch eingestellt… Ich habe Dir ein Screenshot geschickt.
