seid gegrüßt…
zu dem angesagten Thema brauche ich mal eueren Rat,
seit einiger Zeit sende ich mit der 6.1. Version.
Bisher war ich bei einem Sender, bei dem ich mit Icecast problemlos gesendet habe. Nunmehr bin ich bei einem anderen Sender, der mit Shoutcast 2 sendet.
Alles in Allem funzt alles gut, allerdings bekomme ich von der Radioleitung folgende Rückmeldung:
wenn du nach Beendigung einer Sendung vom Stream runtergehst, blockiert dein Player für eine Weile den Stream, eher er wieder anläuft.
Mindestens 50 % der Hörer müssen ihren Player neu starten.
Bei einer Übergabe sollte doch nahtlos der Stream weiterlaufen?.
Das Problem stellt sich auch, wenn keine Übergabe stattfindet. Auch “Stream Plus” kann mir nicht helfen. Liegt es vielleicht an irgendeiner Einstellung in der Konfiguration meines ML?
Vorab ein dickes “Dankeschön” für eure Hilfe.
Allen einen guten Rutsch ins 2020.
Helmut
Also, wenn Du tatsächlich ein Disconnect machst, ist natürlich der Stream getrennt. Daher die Fragen: Wie führst Du die Trennung durch und was sagt das System Log dazu?
willkommen im Forum, auch wenn du schon länger bei mAirList dabei bist (soviel darf ich verraten).
Von deinem bisherigen Sender (der mit Icecast) kamen ja offenbar keine Klagen. Ich nehme an, dass du nicht dein Abschaltverhalten - Encoder trennen - geändert hast, sondern jetzt eben auf Shoutcast 2 streamen musst.
Es könnte durchaus auch mit dem neuen Radiobetreiber und dessen Serverkonfiguration zu tun haben.
Bist du denn der einzige auf dem Sender, der mit mAirList sendet? Oder gibt es noch andere Moderatoren mit dem Programm dort? Vielleicht könnt ihr ja die Encoder-Konfiguration vergleichen?
danke für die freundliche Aufnahme Uli,
mit dem Icecast konnte ich beim vorherigen Sender, ohne den Server (Stream Plus) stoppen zu müssen, auf Sendung gehen. Umgekehrt das Gleiche, musste also nicht den Stream wieder manuell starten.
Per Shoutcast muss der Server gestoppt werden, um den Player zu starten/streamen. Das mal als Hinweis.
Leider sende ich alleine im Team mit mAirList.
Das ist der entscheidende Hinweis.
Habe ich bislang bei noch keinem Radio, bei dem ich in den letzten Jahren gesendet habe, so erlebt.
Standard ist:
Automation vom Server läuft.
Moderator connected auf den Stream, Automation wird unterbrochen (oder läuft unhörbar im Hintergrund weiter).
Sobald der Moderator disconnected (oder die silence detection anspringt), setzt die Automation wieder ein. Von ganz alleine.
Für so was hat mAirList Professional Edition ja diesen sensationellen Stream Monitor, der bei fast allen der von uns ausgestatteten 24/7-Internetradios gute Dienste leistet - und bei vielen anderen Stationen Zusatzaufgaben für Live-Einspielungen von außerhalb übernimmt. Das ist mittlerweile gesunder Standard, wie bereits erwähnt.
Vielleicht sollte die Technik-Leitung deines neuen Radiosenders mal darüber nachdenken.
Dass die Moderatoren manuell den Stream stoppen und wieder starten müssen, ist ja so was von '90er… ach nee, ich habe ja auch erst später angefangen.
Trotzdem: Das ist imho veraltete Technik.
Was mir spontan einfällt: Die Maßnahmen, die du ausführen musst, um den Stream zu starten, in eine Datei packen (*.bat?) und diese Datei wiederum triggern lassen durch Aktionen bei ON AIR bzw. OFF AIR.
Außerdem müsste man, wenn das so stattfinden soll, noch ein paar Fallstricke in der Konfiguration beseitigen (kein on air bei Programmstart, Encoder schaltet on air off air um etc.), aber das ist ein zweiter Schritt.
Ist jetzt nur mal so eine spontane Idee, ohne Gewähr.
Das klingt mir ganz nach ShoutCast mit völlig unkonfiguriertem Transcoder. (sc_trans) Da bist du ja mit mAirList ansich schon Welten in der Zukunft. so haben wir vor 15 Jahren mal angefangen…Ach ne da gabs noch SC1
Aber mit mAirlist ansich hat das rein gar nichts zu tun. Soweit kann ich mich aus dem Fenster lehnen.
Lieber Helmut.
Ich weiß ja das du mit Meta Titelübertragung sendest.
Andere bei deinem Sender nicht. Zumindest weiß ich bei einem das er statisch bei B.U.T.T. keine Titel als Meta überträgt.
Vlt kann es sein, daß damit der Transcoder eures Servers nicht ganz klar kommt.
Versuche mal im Encoder das %a - %b rauszunehmen.
Ich weiß jetzt nicht anhand welcher Parameter euer Server eingestellt ist, aber normalerweise sollte folgendes reichen
“Helmut - Die HörBar”
Hacken kannst du eventuell alle reinsetzen dann wird zumindest bei jedem Element das du spielst das: "Helmut - Die HörBar" aktualisiert.
Obs hilft kann ich nicht versprechen.
Das Titel Logging hab ich dir ja damals eingestellt für deine nachreichende Playliste zum nachlesen das läuft unabhängig vom Encoder weiter.
So langsam beschleicht mich das Gefühl, dass der gesamte Themenkomplex gar nichts mit mAirList an sich zu tun hat.
Selbst wenn es bei den anderen Moderatoren auf dem Stream, die eine andere Software benutzen (für die Home Studio gibt es übrigens Mengenrabatt (Mitte der Seite, Abschnitt “Bestellung”)! ), angeblich so gut klappt, so ändert das doch am Procedere nichts:
Es muss immer händisch ab- und angeschaltet werden.
Jetzt mag es sein, dass in der Software der anderen irgendein Script o.ä. im Hintergrund werkelt, das diesen Vorgang automatisiert - aber das kannst du in mAirList auch.
Ihr müsstet euch da nur mal entsprechend zusammentun - oder der “Techniker” fragt @TomJumbo83.
Soweit ich das momentan überblicke, hat das weder mit mAirList noch mit Stream plus zu tun.
Das Problem trat ja erst auf, als du den Sender gewechselt hast. Daher wäre es naheliegend…
Ich habe die Tage mit Uli über das Problem gesprochen. Shoutcast (2) habe ich schon vor Jahren ausgemustert, aus Gründen…
Nun sind mir beim Studium der Webseite des Streamserverproviders, einige Screenshots aufgefallen.
Was hat man Dir gesagt, in welcher Reihenfolge, Du beim Disconnect vorgehen sollst?
Erst mAirlist trennen oder erst den AutoDJ starten und dann trennen?
Richtig wäre meiner Meinung nach (auch wenn ich dieses sehr Merkwürdige Konstrukt an Streamservertechnik nicht ganz durchblicke, warum man das so macht) erst den AutoDJ zu starten und dann in mAirlist den Encoder zu trennen.
Zu Beginn der Sendung genau anders herum mit einem sehr kurzen Re-Connect Timeout in mAirlist.
Weiterhin kann der Admin einstellen, ob die Hörer getrennt werden sollen, wenn die einspeisende Quelle weg bricht. Das sollte natürlich aus sein.
Ein mAirlist spezifisches Problem, kann ich hier auch erstmal nicht sehen.
Hast Du den Streamserver im Encoder neu Angelegt oder den alten Icecast Stream umgeschrieben?
Hallo Malte,
danke für die >>vielleicht<< hilfreichen Ausführungen,
Um deine Frage zu beantworten
(Hast Du den Streamserver im Encoder neu Angelegt oder den alten Icecast Stream umgeschrieben?)<
der wurde neu angelegt!
meine Frage zu:
“”" Beginn der Sendung genau anders herum mit einem sehr kurzen Re-Connect Timeout in mAirlist.“”"
bedarf das einer Einstellung im mAirlist??
Was genau bedeutet das? Trennen und nach einer gewissen Zeit wieder verbinden? Wie lang genau ist „sehr kurz“? Ich kann mir vorstellen, daß das mit einem kleinen Skript durchführbar ist.
Man kann im Encoder von mAirlist einstellen, wie lange er wartet, bis er einen neuen connect Versuch startet, nachdem getrennt wurde oder der vorherige connect Versuch fehlgeschlagen ist.
Ich weiß nur gerade nicht, ob 1 Sekunde, der kleinste wert ist oder 0 und damit sofort wieder versucht wird, zu connecten.
Da aber beim verbinden, bisher kein Problem war, sollte das ja so passen, wie es ist, es seih denn man hat Dir das bisher von der Reihenfolge anders erklärt und Du änderst das gerade.
Danke Tondose und shorty.xs für eure Hilfsbereitschaft.
Nunmehr schreibt mir Heute ein Hörer folgendes:
""“Übrigens, wenn Du auf den Autodj nach Deiner Sendung umschaltest entsteht nicht nur eine sekundenlange Pause, sondern der Sender verschwindet auch kurz aus dem Display.”""
Ich weiß mir einfach keinen Rat mehr.
Ich neige dazu, wieder auf die vorherige ML-Version 4.1. zurückzugehen, weil das Problem dort nicht war.
beim beenden der Sendung stoppe ich zunächst den Player - unmittelbar danach starte ich den Auto Dj,
beim Versuch es umgekehrt zu machen, bleibt das Problem.
An dieser Stelle wäre es vielleicht sinnhaft, da nochmal reinzugrätschen.
Um sicher auszuschließen, dass es etwas mit mAirList zu tun haben könnte, haben Helmut und ich zusammen mit dem Radiobetreiber (der technisch leider nicht so bewandert ist, wie man es erwarten sollte) versucht, das Problem auf dem Teststream nachzustellen.
Gleich vorab: Ja, es lässt sich reproduzieren.
Nun zum großen ABER, und ich möchte euch damit auf die richtige Fährte locken:
Die Automation muss - von jedem! - Moderator manuell gestoppt und auch wieder gestartet werden.
Dazu muss er sich auf die Streamplus-Seite des Senders einloggen und einen speziell dafür vorgesehenen Button drücken.
Startet man die Automation und disconnected dann via mAirList Encoder, bleibt der Player beim Hörer tatsächlich stehen (Abriss).
Das konnte ich als Hörer nachstellen.
Was ich nicht reproduzieren konnte:
Bei den anderen Moderatoren passiert das - angeblich - nicht, da bleibt die Verbindung erhalten. Konnte ich nicht überprüfen, muss man mal so glauben. Die anderen Moderatoren nutzen SAM, butt und Virtual DJ.
Helmut ist der einzige mAirlist-Anwender in diesem Club. Daher die Arbeitsthese des Radiobetreibers, es müsse ja an mAirList liegen.
Zwar hätte man bei Streamplus auch die Möglichkeit, über Icecast zu streamen, aber das geht - wiederum: angeblich - nicht wegen einer Inkompatibilität mit den Nutzern von Virtual DJ.
Testweise habe ich mir Virtual DJ heruntergeladen und kann in der Konfiguration erkennen: Doch, das geht, warum auch nicht? Sie behaupten jedenfalls, sie hätten eine so alte Version des Programms, dass es damit nicht ginge.
Wer sich ein wenig mit dem Lizenzsystem von Virtual DJ auskennt… den Rest überlasse ich eurem logischen Denkvermögen, ich möchte hier unbewiesen niemandem etwas böses unterstellen.
Eine weitere These, die im Raum steht: Helmut war früher wohl schon mal bei dem Sender, dann allerdings mit mAirList v4.x, und da hätte es diese Probleme angeblich nicht gegeben. Weder Torben noch ich wüssten von einer elementaren Encoder-Änderung, und ich habe mich jetzt bewusst nicht durch alle Changelogs gewühlt.
Aus meiner Perspektive: Mit einem Reconnect hat das überhaupt nichts zu tun. Der disconnect wird ja manuell und bewusst von Helmut (wie auch von mir bei dem Test) ausgelöst. Sobald jedoch die Automation übernehmen soll, bricht beim Hörer die Verbindung ab. Das ist der eigentliche Knackpunkt.
Angeblich nur bei der Verwendung von mAirList.
Na gut: Ja, bei mir ist es auch passiert, auf dem Tester, aber was an dem disconnect soll bei mAirList anders sein als bei den anderen Programmen?
Und warum beschwert sich nur (?) der neue Radiobetreiber von Helmut darüber, sonst aber keiner?
Nutzen alle anderen Streamplus nicht (mehr)?
Sind sie auf Streamplus Icecast umgestiegen?
Hat der Radiobetreiber etwas übersehen, was bei der Nutzung der anderen Programme bislang nicht aufgefallen ist?
Und, vor allem: Wo bleiben die anderen Beschwerden? Warum trifft es nur Helmut?
Ich bleibe dabei: Das liegt nicht an mAirList. Aber wenn Helmut nun mal unbedingt zu dem Radio möchte…
Lieben Dank Uli für die ausführliche Umschreibung,
hier nochmal ein kurzer Hinweis zum Ablauf, vielleicht auch eine Überlegung zur Lösung des Problems:
bei dem jetzigen Radiobetreiber (Ktl) war ich schon einmal 2 Jahre und habe mit der 4.1 Version problemlos (über Shoutcast 2) gesendet.
Danach bin ich für eine Zeit bei einem Sender (MWA) gewesen, der mit Icecast sendet. Bei der Konfiguration funktionierte die Serververbindung anfänglich nicht, erst nach dem Update zur 6.1 'Version.
Nunmehr bin ich zurück zu (Ktl) und nun stellt sich das beschriebene Problem.
Der Encoder wurde NEU eingerichtet auf Shoutcast2, allerdings funktioniert nur die Bezeichnung 1 unter (Stream ID (SC v2); setze ich die 2, bekomme ich keine Verbindung.
