Radio-Player funktioniert nicht? Lösungen für Stream, Titelanzeige und Autoplay

Ein Player auf deiner Website, der nicht abspielt oder zwar spielt, aber nicht anzeigt, was gerade läuft, hat fast immer eine von wenigen Ursachen. Die meisten liegen zwischen deinem Stream-Server und dem Browser, nicht im Player selbst – und jede hat ein typisches Erkennungsmerkmal.

Füge zuerst deine Stream-URL in den Tester unten ein. Er zeigt dir, ob die URL Audio liefert, in welchem Format, ob sie über HTTPS läuft und ob Now-Playing-Daten gefunden wurden. Such dann dein Symptom in der Tabelle und spring zum passenden Abschnitt.

Symptom, Ursache, Lösung

Der Stream spielt nicht ab

Die URL ist eine Webseite, kein Stream

Der häufigste Fehler. Stream-Hoster geben dir mehrere URLs: eine öffentliche „Hören"-Seite, eine Playlist-Datei (.pls oder .m3u), eine Statusseite und den eigentlichen Audio-Stream. Nur Letzterer spielt in einem Website-Player.

Was eine URL liefert, prüfst du mit curl. Das Tool ist auf jedem Mac, jedem Linux-Rechner und ab Windows 10 vorhanden:

curl -I https://stream.example.com/live

Achte auf die Zeile Content-Type. audio/mpeg (MP3), audio/aac oder audio/aacp (AAC) und application/vnd.apple.mpegurl oder application/x-mpegURL (HLS) sind Audio. text/html ist eine Webseite. audio/x-scpls oder audio/x-mpegurl ist eine Playlist-Datei: Lade sie herunter, öffne sie in einem Texteditor und verwende die Stream-URL, die darin steht.

Manche Stream-Server beantworten HEAD-Anfragen (-I) nicht richtig. Bekommst du einen Fehler, hol dir nur die Header einer normalen Anfrage und brich nach fünf Sekunden ab:

curl -s -D - -o /dev/null -m 5 https://stream.example.com/live

Die Timeout-Meldung am Ende ist normal; entscheidend sind die Header darüber.

Ein http://-Stream auf einer https://-Website

Läuft deine Website über HTTPS (was sie sollte) und beginnt deine Stream-URL mit http://, behandelt der Browser den Stream als gemischten Inhalt (Mixed Content). So beschreibt MDN die Regel: „<audio>/<video>/<img> HTTP requests on HTTPS pages are auto-upgraded to HTTPS (blocked if host is an IP address)^[1]".

Der Browser versucht also stillschweigend die HTTPS-Version deiner Stream-URL. Hat dein Stream-Server unter dieser Adresse keinen HTTPS-Zugang oder verwendet die URL eine IP-Adresse statt eines Domainnamens, schlägt der Stream fehl. Auf der Website lässt sich das nicht beheben. Frag deinen Stream-Hoster nach einer HTTPS-Stream-URL; die meisten bieten eine an, manchmal auf einem anderen Port oder Hostnamen.

Schnelltest: Ändere http:// in deiner Stream-URL zu https:// und führe den curl -I-Befehl von oben aus. Schlägt er fehl, muss dein Hoster dir die HTTPS-Adresse geben.

Der Codec wird nicht unterstützt

MP3 und AAC laufen in allen aktuellen großen Browsern auf Desktop und Mobilgeräten. Andere Formate wie Ogg-Vorbis-, Opus- oder FLAC-Streams spielt nicht jeder Browser ab; meist sind Apples Browser die Ausnahme. Läuft dein Stream in einem Browser, im anderen aber nicht, prüf den Content-Type – und wenn es weder MP3 noch AAC ist, bitte deinen Hoster oder stell deinen Encoder so ein, dass ein zusätzlicher MP3- oder AAC-Mountpoint bereitsteht.

Kein Songtitel, kein Interpret

Läuft Audio ohne Titel, kommt der Player nicht an deine Now-Playing-Daten. Diese Daten stammen in den meisten Setups nicht aus dem Audio selbst, sondern von einem Status-Endpunkt deines Stream-Servers oder Hosters, den der Player (oder die Plattform dahinter) alle paar Sekunden abfragt. Wo er liegt, hängt von deinem Hoster ab:

Du kannst jede Quelle selbst prüfen. Bei Icecast rufst du die Adresse deines Servers mit /status-json.xsl am Ende auf und suchst nach einem title-Feld für deinen Mountpoint:

curl -s https://stream.example.com/status-json.xsl

Ob Titel im Stream mitgesendet werden, siehst du, wenn du ICY-Metadaten anforderst und nach einem icy-metaint-Header suchst:

curl -s -H "Icy-MetaData: 1" -D - -o /dev/null -m 5 https://stream.example.com/live | grep -i icy

Kein icy-metaint und ein leerer Titel im Status bedeuten meist, dass dein Encoder (BUTT, Mixxx, deine Playout-Software) keine Titel sendet. Aktiviere in den Encoder-Einstellungen die Metadaten bzw. die Option zum Senden der Songtitel.

Ein reiner Browser-Player hat eine zusätzliche Hürde: Viele Stream-Server senden nicht die CORS-Header, die ein Browser braucht, um ihre Statusseiten von einer anderen Website aus zu lesen. Die Anfrage wird also blockiert, obwohl die Daten vorhanden sind. Deshalb holen die meisten Player ihre Now-Playing-Daten über einen eigenen Server.

Bei RadioSiteMaker erkennt der Player die gängigen Hoster (Icecast, SHOUTcast, AzuraCast, Radio.co, RadioKing, Live365, laut.fm, Centova Cast, Caster.fm, RadioHost und weitere) und liest ihre Status-Endpunkte serverseitig aus; als Rückfalloption dienen die ICY-Titel im Stream. Wird dein Hoster nicht erkannt oder willst du einen bestimmten Feed nutzen, füge die Adresse im Dashboard unter Settings → Now Playing URL ein und drück den Test-Button neben deinen Stream-Einstellungen. Funktioniert diese URL nicht, liest die Website die Titel aus dem Stream und weist dich darauf hin.

Der Player startet nicht automatisch

Das ist kein Fehler. Die Autoplay-Richtlinie von Chrome: Muted autoplay always allowed; with sound only after user interaction, MEI threshold (desktop), or installed PWA^[6]. Safari und Firefox haben ähnliche Regeln. Ein Radiostream ist Audio mit Ton – er startet also, wenn der Hörer auf Play drückt.

Keine Website kann das umgehen. Player, die scheinbar automatisch starten, sind entweder stummgeschaltet oder profitieren davon, dass der Besucher schon vorher mit der Seite interagiert hat. Plane das von Anfang an ein: ein großer, gut sichtbarer Play-Button direkt im sichtbaren Bereich, auf jeder Seite.

Audio stoppt beim Seitenwechsel

Auf einer normalen Website lädt ein Klick auf einen Link eine neue Seite, und der Browser verwirft die alte – samt Audio-Player. Eingebettete Player und Widgets leben innerhalb der Seite, also stoppen sie ebenfalls. Das gilt für das Embed deines Stream-Hosters genauso wie für unser eigenes kostenloses Now-Playing-Widget.

Die Lösung ist ein Player, der außerhalb des Seiteninhalts sitzt: Die Website lädt neue Seiten in das bestehende Dokument, ohne komplett neu zu laden, und der Player läuft weiter. Ob du das unter WordPress selbst hinbekommst, hängt von Theme und Plugins ab; es von Grund auf zu bauen ist ein echtes Projekt. Sender-Websites von RadioSiteMaker funktionieren ab Werk so. Weitere Möglichkeiten findest du in der Anleitung wie du einen Live-Player auf deiner Website einbindest.

HLS-Streams, die nur in Safari laufen

Safari spielt HLS (.m3u8) nativ ab. Chrome, Firefox und Edge brauchen auf dem Desktop eine JavaScript-Bibliothek wie hls.js, die Playlist und Audio-Segmente über ganz normale Web-Anfragen herunterlädt. Diese Anfragen unterliegen CORS: Der HLS-Host muss mit einem Access-Control-Allow-Origin-Header antworten, der deine Website zulässt.

So prüfst du das:

curl -s -D - -o /dev/null -H "Origin: https://www.yourstation.com" https://hls.example.com/live/playlist.m3u8 | grep -i access-control

Fehlt die Zeile access-control-allow-origin, blockiert der Host die Wiedergabe im Browser auf fremden Websites. Bitte ihn, CORS zu aktivieren, oder nutze stattdessen seinen MP3-/AAC-Stream. Der Player von RadioSiteMaker lädt hls.js bei HLS-Streams automatisch, kann aber einen Host, der Cross-Origin-Anfragen blockiert, nicht umgehen.

Wiedergabe stoppt im Hintergrund auf dem Handy

Eine Website spielt Audio im Browser des Handys ab, und das Betriebssystem entscheidet, wie lange ein Browser im Hintergrund weiterläuft. Ganz ehrlich, was eine Website nicht garantieren kann:

• Die Wiedergabe kann bei gesperrtem Bildschirm oder in einer anderen App weiterlaufen, aber das System kann den Browser jederzeit pausieren oder beenden, etwa um Akku zu sparen, im Stromsparmodus oder bei knappem Arbeitsspeicher.
• Ein Anruf, eine andere App mit Audio oder ein Benachrichtigungston kann die Wiedergabe unterbrechen, und der Browser setzt sie womöglich nicht von selbst fort.
• Steuerelemente auf dem Sperrbildschirm und im Kontrollzentrum hängen bei Websites vom Browser ab; versprich sie deinen Hörern nicht.

Hört ein großer Teil deines Publikums im Hintergrund, ist eine eigene App der zuverlässigere Weg. Mehr dazu unter eine mobile App für deinen Radiosender und zu den Abwägungen in App vs. Website.

Häufig gestellte Fragen

Warum läuft mein Stream in VLC, aber nicht auf meiner Website?

VLC spielt fast jedes Format ab, über einfaches HTTP, aus einer Playlist-Datei oder von einer IP-Adresse. Ein Browser auf einer HTTPS-Website ist strenger: Er braucht die direkte Stream-URL, über HTTPS, in einem unterstützten Format (MP3, AAC oder, außerhalb von Safari mit hls.js, HLS). Prüf die URL mit dem Stream-Tester, um zu sehen, was davon fehlt.

Meine Stream-URL hat eine Portnummer wie :8000. Ist das ein Problem?

Für sich genommen nicht. Das Problem ist meist, dass der Port nur einfaches HTTP bedient. Frag deinen Hoster, ob es für denselben Stream eine HTTPS-Adresse gibt; sie kann einen anderen Port wie 8443 oder einen anderen Hostnamen verwenden.

Wo finde ich die echte URL meines Streams?

Im Dashboard deines Stream-Hosters, meist unter „Stream-URL", „Mountpoint" oder „Direktlink". Hast du nur einen .pls- oder .m3u-Link, lade die Datei herunter und öffne sie in einem Texteditor; die Stream-URL steht darin. Prüf das Ergebnis mit curl -I und achte auf einen Audio-Content-Type.

Warum zeigt der Player meines Hosters die Songtitel an, meiner aber nicht?

Der Player deines Hosters liest dessen eigene Status-API von dessen eigener Domain und läuft deshalb nicht in die CORS-Beschränkung, die deine Website trifft. Lies den Status-Endpunkt über einen Server aus, nutze eine Plattform, die das tut, oder prüf, ob dein Hoster eine öffentliche Now-Playing-API mit aktiviertem CORS anbietet.

Kann ich den Player beim Laden der Seite automatisch starten lassen?

Nicht mit Ton. Browser erlauben Audio erst, nachdem der Besucher mit der Seite interagiert hat, und keine Website-Einstellung kann das aushebeln. Mach stattdessen den Play-Button gut sichtbar.