HLS-Livestream bleibt stehen: Veraltete Playlist oder fehlendes Segment?
Mediensequenz und neuestes Segment prüfen, CDN-Cache und Player-Probleme trennen. Mit reproduzierbarem HTTP-Test und klaren Testgrenzen.
Ein Livebild kann stehen bleiben, obwohl die Webseite und die oberste .m3u8-Adresse weiterhin 200 zurückgeben. Dieser Status allein erklärt wenig. Der Player erhält möglicherweise immer wieder dieselbe Medien-Playlist. Oder er sieht ein neues Segment in einer aktualisierten Playlist, kann dieses Segment aber nicht abrufen. Für beide Fehler sind unterschiedliche Komponenten und Maßnahmen zuständig.
Diese Anleitung zeigt, welche wenigen Netzwerkdaten zur Unterscheidung reichen. Untersuchen Sie nur Streams, die Ihnen gehören oder für deren Prüfung Sie berechtigt sind. Entfernen Sie vor dem Weitergeben von Logs signierte Query-Parameter, Cookies, Token, Zuschauerkennungen und IP-Adressen.
Prüfmethode – 17. September 2026: Wir haben mit Node.js 24.12.0 einen lokalen HTTP-Test über die Loopback-Schnittstelle ausgeführt. Die ersten beiden Antworten auf /live.m3u8 waren identisch: Mediensequenz 100 mit den Segmenten 100–102. Die dritte Antwort sprang auf Sequenz 101 und enthielt 101–103. Segment 102 lieferte 200; für das neu aufgeführte Segment 103 war absichtlich 404 eingerichtet. Damit wurden zwei unterschiedliche Beobachtungen auf HTTP-Ebene reproduziert: eine unveränderte Playlist und eine fortgeschrittene Playlist mit einem nicht verfügbaren Segment. Der Test liefert Textmarkierungen, kein dekodierbares Video. Nicht getestet wurden tatsächliche Wiedergabe, das Wiederholungsverhalten von hls.js, ein Live-Encoder, ein CDN oder die Wiederverbindung eines Geräts. Das Testskript liegt im Projekt unter scripts/test-live-hls-playlist-diagnosis.cjs.
Mit der Medien-Playlist beginnen, nicht mit der Master-Adresse
Eine Multivarianten- oder Master-Playlist beschreibt auswählbare Varianten. Die Live-Medien-Playlist der ausgewählten Video-, Audio- oder Untertitelspur listet dagegen die aktuell verfügbaren Segmente auf. Eine erfolgreiche Anfrage an die Master-Playlist beweist nicht, dass die ausgewählte untergeordnete Playlist aktuell ist. Den Unterschied erläutert unser Leitfaden zu Master- und Medien-Playlists.
Öffnen Sie vor einem Neuladen des Players die Entwicklertools und bewahren Sie das Netzwerkprotokoll auf. Ermitteln Sie die tatsächlich gewählte Medien-Playlist-Anfrage, ihre endgültige URL nach Weiterleitungen und die folgenden Segmentanfragen. Filtern Sie nach m3u8, ts, m4s und dem tatsächlichen Segmentpfad. Für eine Checkliste hilft der Leitfaden zur M3U8-Analyse in Entwicklertools.
Speichern Sie mindestens zwei Playlist-Antworten, nicht nur deren Statuscodes. Notieren Sie jeweils #EXT-X-MEDIA-SEQUENCE, die erste und letzte Segment-URI, #EXT-X-TARGETDURATION, das Vorhandensein von #EXT-X-ENDLIST, die Antwortzeit sowie – falls vorhanden – Date, Age, Cache-Control, ETag und Last-Modified. Manche Header fehlen; halten Sie das fest, statt Werte zu erfinden.
Zwei typische Fehlersignaturen erkennen
| Netzwerkverlauf | Was er belegt | Nächste Prüfung |
|---|---|---|
| Playlist-Anfrage scheitert mit 4xx/5xx oder Netzwerkfehler | Der Client hat keine brauchbare Playlist erhalten | Origin, CDN, Berechtigung, DNS oder Verbindung |
| Mehrere Antworten sind Byte für Byte gleich; Sequenz und neueste URI bleiben unverändert | In diesen Antworten hat der Client keine neuen Medien entdeckt | Veröffentlichungszeit, Cache-Alter, Origin- gegen Edge-Antwort, Neuladen im Player |
| Sequenz und neueste URI rücken vor, das neue Segment liefert aber 404 | Die Playlist wurde möglicherweise vor dem Segment veröffentlicht oder der Segmentpfad ist falsch | Reihenfolge beim Packaging, Origin-Objekt, CDN-Verteilung, URL-Auflösung |
| Segment liefert 200, die Wiedergabe steht dennoch | HTTP-Erreichbarkeit genügt nicht | Antwortinhalt, Medienzeitstempel, Dekodierung, Pufferung, Player-Fehler |
Playlist enthält #EXT-X-ENDLIST | Laut Playlist kommen keine Segmente mehr hinzu | Prüfen, ob die Veranstaltung wirklich beendet ist |
Eine einzelne unveränderte Antwort beweist noch keinen Defekt. Zwischen zwei Veröffentlichungen bleibt eine Live-Playlist normalerweise gleich. Vergleichen Sie die Zeitpunkte mit der Zieldauer und sammeln Sie genügend Schnappschüsse, um ein Fortschreiten erkennen zu können. Ebenso beweist ein Segment mit Status 200 kein dekodierbares Video: Auch eine HTML-Fehlerseite oder ein inkompatibles Fragment kann mit Erfolgscode ausgeliefert werden.
Den Takt der Playlist richtig einordnen
RFC 8216 verlangt, dass ein Client eine aktive Live-Medien-Playlist regelmäßig neu lädt. Nach einer geänderten Playlist wartet er laut Spezifikation vor dem nächsten Versuch mindestens eine Zieldauer, nach einer unveränderten mindestens eine halbe Zieldauer. Für die Veröffentlichung neuer Versionen durch den Server gelten eigene Zeitgrenzen. Hat der Stream eine Zieldauer von acht Sekunden, ist ein Client nicht schon deshalb „festgefahren“, weil er nicht jede Sekunde neu lädt.
Das sind Protokollregeln, keine Garantie für das Verhalten eines fremden CDN oder einer Anwendung. Low-Latency HLS kann blockierendes Neuladen der Playlist und Teilsegmente verwenden. Beurteilen Sie daher den konkreten Stream statt eines pauschalen festen Abfrageintervalls. Apple dokumentiert das blockierende Neuladen für diesen Modus gesondert.
Bei einem üblichen gleitenden Live-Fenster verschwinden ältere Segment-URIs der Reihe nach; #EXT-X-MEDIA-SEQUENCE steigt entsprechend. Ein Sprung nach einem längeren Netzausfall kann bedeuten, dass der Player hinter das verfügbare Fenster zurückgefallen ist. Ob der Decoder wieder läuft, verrät die Sequenznummer allein nicht. Prüfen Sie Segmentverfügbarkeit und Wiedergabezeit getrennt.
Ein kontrollierter Netzwerkverlauf
Unser Test gab diese drei Playlist-Schnappschüsse nacheinander zurück. Er wartete keine echten Zieldauer-Intervalle ab; geprüft wurde der Antwortinhalt, nicht die Einhaltung des Timings.
| Anfrage | HTTP | Mediensequenz | Aufgeführte Segmente | Status des neuesten Segments |
|---|---|---|---|---|
| Erste | 200 | 100 | 100, 101, 102 | 102 → 200 |
| Zweite | 200 | 100 | 100, 101, 102 | Unveränderte Antwort |
| Dritte | 200 | 101 | 101, 102, 103 | 103 → 404 |
Die zweite Antwort zeigt nur, dass zu diesem Zeitpunkt kein neues Segment angekündigt wurde. Die dritte belegt, dass die Playlist danach vorgerückt ist, während das neu angekündigte Objekt unter der geprüften URL nicht verfügbar war. Keine dieser Beobachtungen beweist für sich, wie sich ein echter Videoplayer erholen würde. Der Netzwerkverlauf liefert Encoder- oder CDN-Verantwortlichen aber eine konkrete erste fehlgeschlagene Anfrage statt der ungenauen Meldung „Livestream eingefroren“.
Belege für Origin, CDN und Player getrennt sammeln
Wenn ein Edge-Server immer eine alte Playlist ausliefert, vergleichen Sie dieselbe Playlist am Origin und am CDN unter gleichwertiger Berechtigung. Notieren Sie die endgültige URL und die Cache-Header. Ein hoher Age-Wert kann ein Hinweis sein; aus einem einzigen Header lässt sich jedoch weder die gesamte Cache-Richtlinie ableiten, noch stellt jedes CDN seinen Zustand gleich dar. Zufällige Query-Parameter sind keine dauerhafte „Lösung“: Bei signierten URLs und Cache-Schlüsseln können sie die Diagnose verfälschen oder riskant sein.
Wenn die Playlist voranschreitet, aber ein Segment fehlt, rufen Sie genau die URI auf, die relativ zur URL der Medien-Playlist aufgelöst wurde. Prüfen Sie sowohl Status als auch Antwortinhalt. Ein Segment, das angekündigt wird, bevor es abrufbar ist, kann die Wiedergabe trotz frischer Playlist anhalten. RFC 8216 verlangt, dass aufgeführte Segmente unmittelbar verfügbar sind. Untersuchen Sie die Veröffentlichungsreihenfolge des Packagers und ob Origin und CDN das neue Objekt rechtzeitig bereitstellen.
Sind Playlist- und Segmentanfragen erfolgreich, wenden Sie sich dem Player zu. Bei hls.js können Sie LEVEL_LOADING, LEVEL_LOADED oder LEVEL_UPDATED, FRAG_LOADING, FRAG_LOADED und Details von ERROR protokollieren, einschließlich der Einstufung als fataler Fehler. Die API unterscheidet Fehler beim Laden eines Levels von Fehlern beim Laden eines Fragments. Gehen Sie nicht davon aus, dass dieselben Ereignisse bei nativer Safari-Wiedergabe identisch auftreten; nutzen Sie dort die Mediendiagnose des Browsers. Für allgemeinere Puffersymptome hilft unsere HLS-Pufferdiagnose.
Was nach einer Wiederverbindung zu testen ist
Erfassen Sie für jeden unterstützten Browser und jedes echte Gerät, ob die Playlist-Anfrage wieder einsetzt, ob Sequenz und neueste URI voranschreiten, ob das nächste Segment geladen wird und ob die Wiedergabezeit wieder läuft. Testen Sie eine kurze Offline-Phase und eine, die lang genug ist, damit das gleitende Fenster die alte Position überholt. Ein schmaler Desktop-Viewport ersetzt keinen Test des Funknetz-Wechsels oder der Hintergrundwiedergabe auf einem Telefon.
Rufen Sie nicht bei jedem Netzwerkereignis automatisch video.play() auf und melden Sie dann „Erfolg“. Vielleicht hat der Nutzer absichtlich pausiert, vielleicht verhindert eine Browserregel den Start, oder der Stream liefert weiterhin alte Daten. Halten Sie eine sichtbare, vom Nutzer gesteuerte Play-Schaltfläche bereit. Wenn die Quelle geladen ist, die Wiedergabe aber nicht beginnt, hilft die HLS-Autoplay-Diagnose.
Ein brauchbarer Vorfallsbericht enthält die letzte funktionierende Mediensequenz, die erste unveränderte oder fehlgeschlagene Antwort, den genauen Segmentstatus, Cache-Header, Browser- und Player-Versionen sowie die Information, ob die Wiedergabe wieder anlief. Damit lässt sich „CDN liefert noch das alte Fenster“ von „Player kann das neue Segment nicht dekodieren“ unterscheiden.
Quellen
- RFC 8216: HTTP Live Streaming – Aktualisierung und Neuladen von Live-Playlists
- Apple: Aufbau eines gleitenden Live-Playlist-Fensters
- Apple: Low-Latency HTTP Live Streaming aktivieren
- hls.js: Ereignisreferenz
- hls.js: Referenz zu Fehlerdetails
Verfolgen Sie die Medien-Playlist und das erste neu angekündigte Segment in dieser Reihenfolge. Dort, wo sich die Belege nicht mehr weiterentwickeln, beginnt die nächste Untersuchung – nicht beim eingefrorenen Bild allein.