Pufferung und Ruckeln beheben: eine Checkliste, die mit der richtigen Frage beginnt
Die App unterscheidet bereits neun verschiedene Wiedergabefehler. Zu wissen, welcher davon vorliegt, macht aus einem vagen Problem eine kurze Liste.
Die meisten Ratschläge zur Pufferung beginnen mit "prüfen Sie Ihre Internetverbindung". Das haben Sie längst getan. Der bessere erste Schritt ist herauszufinden, welche von mehreren Störungen bei Ihnen vorliegt, denn jede hat eine andere Lösung und die App hat sie für Sie bereits eingeordnet.
Neun Störungen, nicht eine
Der Player kennt kein einheitliches "funktioniert nicht". Er ordnet Fehler in 9 Arten ein, und die Art entscheidet, welche Wiederherstellung läuft:
F1 NetStall no bytes arriving at all
F2 SilentEof the stream ended without you asking
F3 HardError the stream would not open
F4 DemuxStarve bytes arriving, no frames coming out
F5 VideoFreeze picture stopped, audio still playing
F6 TotalFreeze both stopped, data still flowing
F7 BlackFrames everything healthy, picture is black
F8 ClockStall the input clock stopped advancing
F9 RebufferLoop repeated rebuffering in a rolling window
Das sind verschiedene Probleme. F1 liegt an Ihrem Netzwerk oder an dem des Anbieters. F4 ist ein Stream, der Füllmaterial statt Video sendet, also ein Problem des Anbieters, an dem Ihre Verbindung nichts ändern kann. F7 ist meist die Quelle, die Schwarzbild liefert, und dagegen hilft kein Neustart.
Nichts wird sofort festgestellt. Ein Fehler muss erst ein Zeitfenster überdauern: 4 Sekunden ohne ein einziges Byte, 6 Sekunden ausgehungerter Demuxer, 4 Sekunden stehendes Video, 4 Sekunden vollständiges Einfrieren. Diese Fenster gibt es, weil ein Aussetzer von 2 Sekunden kein Fehler ist. Ein Player, der auf jeden einzelnen reagieren würde, verbrächte den Abend damit, einen Stream neu zu starten, der sich ohnehin gleich wieder fängt.
Was der Player längst tut, bevor Sie irgendetwas tun
Drei Dinge, damit Sie sie nicht doppelt machen.
Er passt seine Puffer selbst an. Wenn sich das Nachpuffern wiederholt, hebt der Player seine Cache-Untergrenze je Feststellung um 1000 Millisekunden an, bis 5000. Auf einer grenzwertigen Verbindung hat die App sich also wahrscheinlich längst mehr Puffer gegeben als die 1200 Millisekunden Netzwerk-Cache und 800 Millisekunden Live-Cache, mit denen sie startet. Eine Puffereinstellung von Hand hochzudrehen wiederholt oft nur Arbeit, die schon passiert ist.
Er ist außerdem sorgfältig damit, was als Nachpuffern zählt. Eine Episode wird erst gezählt, wenn der Cache unter 62 Prozent fällt, und sie endet bei 88. Diese Hysterese gibt es, weil die Cache-Werte bei Live-HLS an Segmentgrenzen schwanken und das Zählen jeder Delle unterhalb der Vollmarke gesunde Streams als kaputt melden würde.
Und er fängt die Störung ab, die gar keinen Fehler erzeugt, weshalb "es steht einfach nur da" eine echte Kategorie ist. Ein Stream kann aufhören zu senden und dabei seinen Socket offen lassen. Wir haben das gegen einen Fehlerinjektions-Prüfstand getestet, und das Ergebnis war eindeutig: die Differenz des Byte-Zählers geht auf 0 und es gibt überhaupt kein Player-Ereignis. Nichts meldet einen Fehler. Nichts wirft eine Ausnahme. Das Bild bleibt auf dem letzten Einzelbild stehen, das es hatte.
Deshalb ist die Erkennung ein Timer, der Zähler beobachtet, und kein Fehlerhandler, und deshalb gibt es 4 Sekunden Wartezeit, bevor irgendetwas passiert. Wenn Ihr Stream einfriert und ein paar Sekunden später weiterläuft, haben Sie diesem Mechanismus bei der Arbeit zugesehen.
Dass die Wiederholungsseite der größte Hebel sein würde, hatte ich nicht erwartet. Mit beiden Verbindungskarenzzeiten auf 8 Sekunden verbrachte ein vollständiger Byte-Stillstand 8 seiner 15.7 Sekunden damit, eine URL neu zu starten, die immer noch tot war. Die Wiederholungs-Karenzzeit auf 4 Sekunden zu verkürzen, also auf dieselben 4 Sekunden ohne Bytes, denen wir bereits zutrauen, einen etablierten Stream zu verurteilen, war die mit Abstand größte Verbesserung der gemessenen Zeit vom Fehler bis zur Alternative. Die Leiter erlaubt außerdem genau 1 Neustart, bevor die Quelle gewechselt wird, weil Felddaten gezeigt haben, dass ein zweiter Neustart einer toten Quelle nie hilft.
Die Checkliste, in der Reihenfolge, die am schnellsten etwas findet
1. Betrifft es einen Sender oder alle? Ein einzelner Sender ist ein Problem der Quelle, und keine Einstellung auf Ihrem Rechner behebt es. Wenn Ihr Anbieter denselben Sender in einer anderen Qualität oder von einem anderen Server anbietet, probieren Sie das. Alle Sender heißt: es liegt bei Ihnen.
2. Kabel oder Funk? Das ist die mit Abstand ergiebigste Frage. Ein Live-Stream ist ein durchgehender Echtzeit-Lesevorgang, und grenzwertiges WLAN erzeugt genau das Symptom, das die Leute dem Player anlasten. Probieren Sie einmal ein Kabel, rein zur Diagnose.
3. Läuft derselbe Sender auf einem anderen Gerät im selben Netz? Wenn er auf einem Telefon läuft und auf dem PC nicht, haben Sie das Problem auf den Rechner eingegrenzt. Wenn er auf beiden scheitert, haben Sie es auf das Netzwerk oder den Anbieter eingegrenzt.
4. Sind Sie an Ihrem Verbindungslimit? Zwei Verbindungen und drei Geräte ergeben ein Ruckeln, das nach Bandbreite aussieht und keine ist. Maximale Verbindungen erklärt, warum eine Verbindung belegt bleiben kann, nachdem Sie das Zuschauen beendet haben.
5. Bleibt das Bild wirklich stehen, oder ist es Ruckeln? Regelmäßiges, gleichmäßiges Stocken bei Schwenks ist meist eine nicht passende Bildwiederholrate: 50-Hz-Material auf einem 60-Hz-Bildschirm. Das ist eine Anzeigeeinstellung und kein Pufferproblem, und keine noch so große Zwischenspeicherung ändert daran etwas. Ein Notebook über HDMI anschließen behandelt das.
Wenn Sie einen Proxy oder ein VPN in der App verwenden
Ein Verhalten sollten Sie erwarten. Wenn ein Verbindungsprofil eingerichtet ist, scheitern Medien, die der Transportweg nicht tragen kann, geschlossen, statt still auf eine direkte Verbindung zurückzufallen. Das ist Absicht. Eine Datenschutzeinstellung, die unbemerkt aufhört zu greifen, ist schlimmer als eine, die sichtbar aufhört zu funktionieren.
Ein Sender, der vor der Einrichtung eines Profils lief und danach scheitert, ist also nicht zwangsläufig ein kaputtes Profil. Es kann ein Stream sein, dessen Schema das Relais nicht tragen kann und der sich weigert, nach außen zu lecken. Das ist das Profil bei der Arbeit. VPNs und Stream-Leistung behandelt, worauf es dort wirklich ankommt.
Wenn das Bild eingefroren ist, der Ton aber weiterläuft, ist das genau F5, und dafür gibt es einen eigenen Artikel: Video friert ein, Ton läuft weiter für den Mechanismus und Ton, aber kein Bild für das, was dagegen hilft.
Was dieser Artikel gemessen hat22 Behauptungen, jeweils mit den Beweisen dahinter
| Anspruch | Beweise | Gezählt |
|---|---|---|
| Wiedergabefehler werden in neun Arten eingeteilt, statt als ein einziger allgemeiner Fehler gemeldet zu werden, und die Art entscheidet, welche Wiederherstellungsstufe läuft. | n = 9 | 31.08.2026 |
| Jeder Fehler muss ein festes Zeitfenster lang anhalten, bevor er festgestellt wird: 4 Sekunden ohne ein einziges Byte, 6 Sekunden ausgehungerter Demuxer, 4 Sekunden stehendes Video und 4 Sekunden vollständiges Einfrieren. | n = 4 | 31.08.2026 |
| Eine Nachpuffer-Episode wird erst gezählt, wenn der Cache unter 62 Prozent fällt, und sie endet bei 88 Prozent, weil die Cache-Werte bei Live-HLS an Segmentgrenzen schwanken und das Zählen jeder Delle unterhalb der Vollmarke gesunde Streams melden würde. | n = 1 | 23.08.2026 |
| Wird eine Nachpufferschleife festgestellt, hebt der Player seine eigene Cache-Untergrenze je Feststellung um 1000 Millisekunden an, bis zu einer Obergrenze von 5000 Millisekunden, statt die Zuschauerin oder den Zuschauer um eine Einstellungsänderung zu bitten. | n = 1 | 23.08.2026 |
| Die Standardpufferung beträgt auf dem Vollbild-Live-Pfad 1200 Millisekunden Netzwerk-Cache und 800 Millisekunden Live-Cache, gegenüber 350 und 200 auf einer stummgeschalteten Multiview-Kachel. | n = 1 | 23.08.2026 |
| Ein Stream, der aufhört zu senden und dabei seinen Socket offen lässt, erzeugt überhaupt kein Player-Ereignis. Die Differenz des Byte-Zählers geht auf null und sonst ändert sich nichts, weshalb die Erkennung ein Timer sein muss und kein Fehlerhandler. | n = 1 | 16.08.2026 |
| Der gesamte Detektor kennt drei Ausrollstufen: Active, Shadow (nur erkennen und protokollieren) und Off. Die Voreinstellung ist Active, und die Stufe lässt sich über die Konfiguration ohne Neuübersetzung setzen. | n = 3 | 01.09.2026 |
| Die Zähler werden einmal pro Sekunde abgetastet, solange ein Stream gesund wirkt, und zweimal pro Sekunde, sobald er verdächtig wirkt. | n = 2 | 01.09.2026 |
| Das Öffnen eines Streams wird getrennt vom Abspielen bewertet: 15 Sekunden bis zum ersten Bild bei einem Kaltstart, 8 Sekunden bei einem Wiederherstellungsversuch, wobei völlige Funkstille im Netzwerk nach 8 Sekunden kalt und nach 4 Sekunden bei einem erneuten Versuch verurteilt wird. | n = 4 | 01.09.2026 |
| Die Verkürzung der Wiederholungs-Karenzzeit war die mit Abstand größte Verbesserung der gemessenen Zeit vom Fehler bis zur Alternative: mit beiden Karenzzeiten auf 8 Sekunden verbrachte ein vollständiger Byte-Stillstand 8 seiner 15.7 Sekunden damit, eine URL neu zu starten, die immer noch tot war. | n = 1 | 01.09.2026 |
| Ein verdächtiger Stream gilt nach 3 Sekunden mit normalen Differenzen wieder als gesund, und 60 zusammenhängende Sekunden Gesundheit setzen die Wiederherstellungsleiter samt ihrer Wartezeiten zurück. | n = 2 | 01.09.2026 |
| Nach einem Sprung durch die Nutzerin oder den Nutzer dürfen die Zähler 5 Sekunden lang stehen bleiben, ohne dass das als Fehler zählt. | n = 1 | 01.09.2026 |
| Sender, die kein gewöhnliches Video sind, bekommen eigene Zeitfenster: 15 Sekunden für einen Sender mit niedriger Bildrate und 12 Sekunden für einen als reinen Ton eingestuften, gegenüber 4 Sekunden für normales Video. | n = 3 | 01.09.2026 |
| Eine Sitzung wird nach 4 Sekunden als reiner Ton eingestuft. Der Wert liegt bewusst innerhalb der Startkarenz und oberhalb der beobachteten späten PMT-Verzögerungen, weil eine falsch eingestufte Videoquelle ihre Einfrierregeln für den Rest der Sitzung stillschweigend abschalten würde. | n = 1 | 01.09.2026 |
| Störungen im Stream schalten kürzere Einfrierfenster scharf: 3 Diskontinuitäten oder 25 beschädigte Einheiten in einer Abtastung halten die verkürzten Fenster 10 Sekunden lang scharf. | n = 3 | 01.09.2026 |
| In den 10 Sekunden nach einer Wiederherstellung werden die Feststellungsfenster halbiert, weil die Belege, die die Quelle eben noch verurteilt haben, weiterhin gelten. Ein tatsächlich wieder funktionierender Stream treibt seine Zähler sofort voran und erreicht diese Fenster nie. | n = 1 | 01.09.2026 |
| Wiederholungsversuche warten nach der Formel Basis mal zwei hoch Versuch minus eins, gedeckelt bei 30 Sekunden und um plus/minus 20 Prozent zufällig gestreut, sodass der erste Versuch sofort startet und spätere auf 1, 3 und 7 Sekunden anwachsen. | n = 3 | 01.09.2026 |
| Die Leiter erlaubt genau 1 Neustart einer fehlerhaften URL, bevor die Quelle gewechselt wird, weil Felddaten gezeigt haben, dass ein zweiter Neustart einer toten Quelle nie hilft und den Wechsel nur verzögert. | n = 1 | 01.09.2026 |
| Ein Fehler innerhalb der ersten 15 Sekunden einer Sitzung steigt nicht beim Neustart, sondern beim Quellenwechsel in die Leiter ein, mit der Begründung, dass sich die Quelle nie bewährt hat. Reife Sitzungen behalten den Neustart an erster Stelle, damit ein Aussetzer mitten im Zuschauen nie einen Quellenwechsel auslöst. | n = 1 | 01.09.2026 |
| Nachdem die Leiter aufgegeben hat, laufen Hintergrundversuche alle 60 Sekunden weiter und hören nach 30 Minuten ganz auf, sodass nur noch der manuelle Versuch bleibt. | n = 2 | 01.09.2026 |
| Der nahtlose Quellenwechsel fährt den Ersatz auf einem zweiten Decoder hoch und schaltet bei dessen erstem Bild um, kostet während der Überlappung aber eine zusätzliche Anbieterverbindung. Deshalb verweigert der Planer den Wechsel immer dann, wenn diese Verbindung nicht nachweislich frei ist, und fällt auf einen gewöhnlichen Neustart zurück. | n = 1 | 01.09.2026 |
| Wenn ein Verbindungsprofil aktiv ist, scheitern Medien, die der eingestellte Transportweg nicht tragen kann, geschlossen, statt auf eine direkte Verbindung zurückzufallen. | n = 1 | 25.08.2026 |