Notiz an mich selbst: Sollte ein Centova-Radio-Server immer nach kurzer Zeit die Übertragung abbrechen, dann macht es durchaus Sinn mal die Übertragungsrate von der Encoder-Software und der Streaming-Server zu vergleichen. ;-) Es kann nämlich ganz leicht sein, dass am Server zum Beispiel ein Limit von 32 kbit/s eingestellt ist und der Encoder (z.B. die Butt-App) aber versucht mit 128 kbit/s zu übertragen. Das quittiert der Server mit dem Einstellen des Streams bzw. Stopp des Servers.
Can you provide us a screenshot with your encoder? Please note that the maximum bitrate is 32kbps.
Serverroom-Support
Bei meiner Recherche bin ich auch noch über eine iOS-App gestolpert, welche für die „Verwaltung“ eines ShoutCast/IceCast/CentovaCast-Server eingesetzt werden kann. Die App nennt sich „Centova Cast: Control“ und ist von Tobias Niendorf.
Mir ist gestern aufgefallen, dass „mein Radio-Sender“ nicht mehr lief. Als ich dann etwas genauer nachgeforscht habe, stellt ich fest, dass „Butt“ (die Streaming-App auf einem Windows-PC) nicht mehr mit dem Streaming-Server bei Serveroom verbinden konnte. Im weiteren Verlauf habe ich dann festgestellt, dass mein (kostenloser) Account dort auf „Closed“ gestanden ist – Grund nicht mir unbekannt. Nachdem es aber ziemlich genau ein Jahr her war, dass ich mit diesen geklickt Account habe (ursprünglicher Artikel: Radio Station mit „Serverroom.net“ betreiben – Update (Juli 2021) ), bin ich davon erstmal ausgegangen, dass irgendeinen Frist nach einem Jahr endete.
Ich hab daraufhin den Serverroom-Support angeschrieben und folgende Nachricht erhalten:
„Most free accounts were closed for maintenance purposes. Your account is now active, please provide your former IP and port in order to reassign them.„ Quelle: Email vom Serverroom-Support
Dadurch wusste ich schon mal, dass aus irgendwelchen Wartungsgründen mein Account „geclosed“ wurde und ich hab dem Support den von mir verwendeten Port, sowie die Server-URL geschickt – eine IP-Nummer hatte ich schlicht weg nicht.
Darauf hin wurde mein Zugang wieder online geschaltet und ich bekam als weiteren Hinweis, dass das Source-Passwort resetted wurde.
Please try connecting now. The source password has been reset to secret, you will have to change it in your encoder or let us know what you are using in order to change it on the service.An HTTPS stream link is now available as well: http://castXXXX.servcast.net/proxy/USERNAME/stream The link will only work when there is an active stream. Quelle: Email vom Serverroom-Support
Ich musste dann nur noch im Backend des CentovaCast-Servers wieder ein Source-Passwort vergeben und die Kollegen vom Support hatten dann schon wieder meine ursprünglich verwendeten Ports (7134) konfiguriert. Gut finde ich auch, dass mittlerweile einen HTTPS-Stream gibt.
Als auch dies erledigt war, wollte ich mit der Windows-Streaming-App mich wieder verbinden, was aber leider noch nicht ging. Ich musste dann tatsächlich noch den CentovaCast-Server nochmals stoppen und erneut starten. Dann wurden scheinbar alle gemachten Änderungen „sauber“ übernommen und „Butt“ konnte sich wieder connecten und mein Radio-Stream lief wieder. ;-)
Vor einigen Wochen habe ich euch in einem Artikel (Radio-Station mit NiceCast und ServerRoom vom 11. Juni 2021) beschrieben, wie ich eine „Internet Radio Station“ mittels NiceCast (für Mac) und dem Anbieter „Serverroom“ betreiben wollte. Die Theorie war ganz gut, aber in der Praxis hat sich das eine und andere ergeben, weshalb ich heute hier noch schnell ein Update zukommen lassen möchte.
Streaming App „Probleme“
Eigentlich war geplant, dass ich NiceCast für macOS verwende. Doch leider hat sich mein alter Mac mini aus heiterem Himmel verabschiedet und war nicht mehr zu reparieren. Daher musste ich auf eine „Windows Kiste“ ausweichen. Da ich dort nicht so fit bin, welche Streaming Software man denn am besten verwendet, hab ich Google befragt und bin da bei „Rocket Broadcaster“ hängen geblieben. Die App hat mir gut gefallen und auch die Einrichtung des Streams war einfach. Allerdings habe ich die kostenlose, freie Version eingesetzt und da hat man ein paar Einschränkungen. Unter anderem auch, dass man die Bitrate des Streams nicht einstellen kann und per default ist diese bei 128 kbit/s (kbps). Ich dachte mir, dass wäre kein Problem, wenn ich zu Serverroom.net eine höhere Bitrate schicke, die werden es dort eh auf 32kbit/s reduzieren.
Nun wollte ich den Stream in Betrieb nehmen und dabei ist mir aufgefallen, dass erstmal alles wunderbar klappt und ich mein Audio im „Live-Stream“ von Serverroom.Net höre. Aber der Serverroom CentovaCast-Server stellte immer nach ein paar Minuten den Betrieb wieder ein und war im Status „Gestoppet“ – Grund erstmal unbekannt. Ich hab mir dann dort die Settings angeschaut und den einen oder anderen Wert verändert, was aber keine wirkliche Besserung brachte.
Vielleicht eine wichtige CentovaCast-Einstellung?
Ich hab aber eher durch Zufall eine Einstellung bei Serverroom in den Centova-Settings gefunden, dich verändert habe, weil ich denke, dass diese für meinen Einsatzzweck relevant ist. Und zwar nennt sich diese Einstellung: „Disconnect idle sources after xxx Seconds“ und ich interpretiere das so, dass Quellen, die nichts übertragen (also stumm sind) nach einer gewissen Zeit (default waren glaube ich 60 Sekunden) vom Stream getrennt werden. Und da ich in meinen Anwendungsfall „hauptsächlich Stille“ übertrage, dachte ich, dass ich diesen Wert auf Null (0) setze, da damit diese Funktion deaktiviert wird.
Wichtige Einstellung im CentovaCast-Server, die meiner Meinung nach das Trennen „stummer“ Quellen verhindert.
Erkenntnis: 32 kbit/s sind wichtig!
Leider lief der Stream immer noch nicht stabil und bracht nach wenigen Minuten immer ab. Nun kam ich doch wieder auf den 128 kbit-Stream von „Rocket Broadcaster“ zurück und wollte mal probieren, ob diese Bitrate vielleicht damit in Verbindung steht. Also brauchte ich eine andere, alternative Streamer-App, welche zuläßt, dass man die Bitrate relativ frei einstellt.
Übersicht der 3rd Party-Apps für IceCast. Darunter auch „butt“ von Daniel Nöthen, dem ich für die Software natürlich auch eine PayPal-Spende zukommen habe lassen. Ehrensache. ;-)
Anregungen dafür hab ich mir auf der offiziellen IceCast-Webseite geholt, wo es ein Verzeichnis von 3rd Party Apps gibt. Dort habe ich mir dann 2 oder 3 Programme angeschaut, bin aber dann bei „butt“ (broadcast using this tool) von Daniel Nöthen hängen geblieben, weil er kostenlos ist, einfach einzurichten und die Bitrate einstellen lässt.
„butt“ von Daniel Nöthen auf seiner Webseite danielnoethen.de – macht genau dass, was ich brauchte! Flexibel einstellbare Stream-Bitrate.
By the Way: Ich hab auf der Webseite von Daniel gesehen, dass er auch noch weitere Apps anbietet, welche auch durchaus mal interessant sein könnten. Vor allem die iOS App „iziCast“ muss ich mir mal merken, vielleicht hab ich dafür mal einen Einsatzfall.
Andere Apps von Daniel Nöthen, von denen vor allem „iziCast“ für iOS interessant sein könnte (Kosten 6,99 EUR im AppStore).
Nun ist es doch schon wieder einige Stunden her, dass ich auf „butt“ gewechselt habe und seither läuft der Stream ohne Ausfälle! Scheinbar prüft Serverroom.net doch irgendwie ab, welchen „Quellstream“ es bekommt und wenn dieser über den (kostenlosen) 32kbit liegt, beenden sie den Server. So zumindest jetzt mal meine Vermutung. Den seitdem ich mit „butt“ ihnen einen 32 kbit-Stream schickt (und nicht mehr 128 kbit von Rocket Broadcaster) läuft der Stream durch. Also: 32kbit/s sind in diesem Fall wichtig! ;-)
The most common issue that might have caused the disconnections is streaming at a higher bitrate than the allowed one, in your case 32 kbps. If our system detects a higher bitrate, it automatically shuts down the stream.
Serverroom.Net Antwort auf meine Support-Anfrage.
Mit etwas Verspätung bekam ich dann auch meine Vermutung vom Serverroom-Support bestätigt, dass die zu hohe Bitrate der Grund für die Abschaltung des Streaming-Servers war. ;-)
Ich hab bei mir im Schrank einen alten Mac mini (Intel Core2 Duo 1,83GHz, 2 GB RAM, 120GB SSD, OSX 10.7.5) gefunden und überlegt, was ich damit noch machen könnte. Mir ist dann die Idee gekommen, dass ich darauf eine „Radio-Station“ bauen könnte. Sowas hatte ich schon mal vor Jahren und damals hab ich mit NiceCast von https://www.rogueamoeba.com/ schonmal was gebastelt. Den Artikel dazu aus 2011 findet ihr hier.
NiceCast wird zwar nicht mehr weiter entwickelt und vertrieben, aber dankenswerterweise stehen alte Versionen noch zum Download zu Verfügung. Meine alte Lizenz hat dann auch noch gepasst und so stand der Installation der Software nicht mehr im Wege. Ich hab für meine Zwecke und dem installierten macOS die NiceCast-Version 1.10.8 verwendet, weil dass ich die letzte ist, die mit OSX 10.7.5 läuft.
Vielleicht kurz eine Erklärung, wie man NiceCast im Normalfall einsetzten kann.
Normales Einsatz-Szenario von NiceCast.
Im Standard-Szenario ist es so, dass der Rechner (Mac) mit NiceCast an einer DSL-Leitung (oder einer Internet-Verbindung mit fester offizieller IP-Nummer) hängt und über diese IP-Nummer erreichbar ist. Dann geben die Clients, die diesen Audio-Stream hören möchten, „nur“ die URL ein, über die der NiceCast-Rechner erreichbar ist. Diese schaut dann ungefähr so aus:
http://dein-ip-nummer:8000/listen.m3u
Dies hat bei meiner Installation in der Vergangenheit auch gut funktioniert und ich war erstaunt, wie stabil dieses Setup damals gelaufen ist. Über Monate hinweg musste ich den Mac nicht anfassen, der Audio-Stream lief einfach während dieser Zeit durch.
Es sei vielleicht an dieser Stelle noch angemerkt, dass NiceCast durch die App „AUDIO HIJACK®“ abgelöst wurde und man diese für rund 70-80 Euro bekommt. Doch in dieses speziellen Fall wollte ich dieses Geld nicht ausgeben, weil ich erst einmal einen Testaufbau machen und sehen wollte, ob das überhaupt so funktioniert, wie ich mir das ausgedacht habe. Und ausserdem, wie oben schon erwähnt, hatte ich noch eine alte NiceCast-Lizenz, die für diese Zwecke perfekt war. Ausserdem würde „Audio Hijack“ sehr wahrscheinlich nicht mehr auf meinem Uralt-Mac laufen. ;-)
Doch dieses Mal war die Einsatz-Umgebung eine andere und etwas komplizierter. Den alten Mac mit NiceCast installieren und zum Laufen bringen, war bei mir zuhause (direkt am VDSL) kein Problem. Über die (dynamische) IP-Adresse meines DSL-Anschluss war dann auch der Audio-Stream gleich erreichbar. So weit, so gut.
Nun war aber die Location, wo ich das Audio abgreifen wollte, etwas entlegener und die Netzwerk-Setup durchaus komplexer, so dass bei einem Test dort sich herausstellte, dass der Mac nicht über diese Netzwerk-Konstellation erreichbar ist – Mist.
So schaut mein Netzwerk-Setup am aktuell geplanten Standort aus.
Vielleicht noch kurz zum Netzwerk-Setup am aktuell geplanten Standort ein paar erklärende Worte: Nach der „normalen“ Fritzbox (7490), die am VDSL hängt, geht es am LAN-Port 4 mit dem „Gast-Netzwerk“ weiter. Die LAN-Strecke geht dann mittels Devolo DLAN Adapter in ein „Nebengebäude“, wo sich dann eine Ubiquiti Richtfunkstrecke befindet. Mit dieser Funkbrücke wird eine Stecke von ca. 200 Meter Luftlinie überbrückt und die Richtfunkgeräte haben „intern“ ein Transfernetz am laufen. Auf der anderen Seite der Richfunkstrecke geht das Netzwerkkabel des Ubiquiti-Geräts eine weitere (ältere) Fritzbox, die rein als WLAN-Access-Point dient. In dieses WLAN klickt sich das Mac mini ein und hat darüber eine Internet-Verbinden. Durch diese vielen „Hops“ und den verschiedensten Netzwerken, vorallem durch die Problematik, dass ich mit mit dem Mac im Gast-Netzwerk der Haupt-Fritzbox befinde, ist es nicht mehr möglich den Mac von aussen anzusprechen.
Daher musste ich mich ein neues Konzept überlegen, wie ich den den Audio-Stream vom Internet aus erreichbar machen könnte. Nach etwas Internet-Recherche bin ich auf die Möglichkeit gestossen, dass es ja auch noch IceCast bzw. ShoutCast-Server Provider gibt, zu welchen man einen Audio-Stream von einem Client schicken kann und dieser Audio-Stream ist dann über die offizielle IP / URL des Servers erreichbar.
Geplantes Konzept, wie mein Audio-Stream doch noch zu den Clients kommen könnte.
Gedacht war, dass ich mir einen „Server“ suche, der meinen Audio-Stream entgegen nimmt und selbst dann wieder als Audio-Stream „nach aussen weitergibt“.
Ergänzung vom 16. Juni 2021: Ich wollte gestern mal so einen „fast richtigen“ Testlauf machen und dabei ein Mikrofon als Quelle verwenden. Zu diesem Zweck habe ich mit ein günstiges Lavalier-Mikrofon (ca. 10 Euro) mit 3,5mm Klinkenstecker bei Amazon.de (Lavalier Mikrofon für Handy und PC, 2M Mini Omnidirectional Kondensator Lapel Mic mit 2 Transformation, Perfekt für Interview, Videokonferenz, Podcast, Diktat usw.)bestellt. Doch als ich feststellte, dass ich keinen Ton von diesem Mikrofon erhielt, habe ich rausgefunden, dass man bei diesen alten Mac mini´s einen „Mikrofon-Vorverstärker“ bräuchte (oder eben ein Micro mit Batterien), weil es sich bei dem Anschluss am Mac „nur um einen LINE-IN“ handelt. Da ich mein Setup nicht um einen solchen Vorverstärker erweitern wollte, und ich gelesen habe, dass auch USB-Micros funktionieren würden, habe ich kurzerhand ein USB-Lavalier-Mic (ebenfalls bei Amazon.de) bestellt. Dieses hört auf die klangvolle Produktbezeichnung „GeekerChip USB Mikrofon,Omnidirektionaler Kondensator für Computer, Phone, Laptop, Podcast, Interviews, Netzwerksingen, Skype, Audio Video Recording“ und kostet tatsächlich auch nur 8 Euro. Dies werde ich dann noch in den kommenden Tagen testen (hoffentlich funktioniert so ein „modernes Mikrofon“ an meinem betagten Mac mini noch) und ggfs. bei erfolgreicher Installation dann auch verlinken. (Anmerkung bzw. eine Frage: Was ist „Netzwerksingen“?)
Ergänzung vom 21. Juni 2021: Wie oben vielleicht schon irgendwo erwähnt, hatte ich der Problem, dass ich Gast-Netz der Fritz!Box keine Verbindung zum „Radio-Server“ bei „Serverroom“ aufbauen konnte. Ich bin jetzt drauf gekommen, dass das Gast-Netz per default nur „Internet und Email“ zulässt und alle anderen Ports geblockt werden (auch ausgehend!). Zum Glück kann man dieses „Zugriffsprofil“ an der Fritzbox bearbeiten und dort hab ich jetzt mal (ausgehend) alle Ports erlaubt. Ein anschliessender Versuch zeigt, dass dies des Rätsels Lösung war, den nun klappte auch der Connect zum ShoutCast-Server. Und noch kurz ein Satz zum bestellten USB-Mikrofon: Ich hatte ja Bedanken, dass vielleicht dieses Micro nicht von meinem alten Mac mini erkannt werden würde. Doch wie sich herausstellte, kann man mit „Plug&Play“ auch mal wieder Glück haben. Ich hab das Mikrofon angesteckt, es tauchte umgehend in den „Ton-Einstellungen“ von OSX 10.7.5 auf und ich konnte es dort als „Eingang“ auswählen und somit konnte ich auch mit NiceCast auf dieses Device zugreifen. Vielleicht noch eine Merkhilfe bzw. ein Hinweis: Wenn ihr sowas nicht mit einem Mac, sondern mit einer Windows-Maschine realisieren wollt, dann bin ich über den ShoutCast-Client „Rocket Broadcaster“ gestolpert. Der liesst sich laut seiner Webseite recht anständig und ist für kleinere Setups (so wie ich das betreiben möchte) kostenlos.
Cookie-Zustimmung verwalten
Wir verwenden Cookies, um unsere Website und unseren Service zu optimieren.
Funktionale Cookies
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Preferences
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
