Verzögertes, flüssiges Direct Play bei gleichzeitiger Nutzung durch unterschiedliche Clients liegt meist an der Client-Aushandlung oder Verzögerungen im Bereitstellungspfad und nicht an der Videokodierung auf dem Plex-Server.
Dieselbe Mediendatei kann auf einem Client schnell starten und auf einem anderen zögern, weil sich Codec-Unterstützung, Qualitätseinstellungen, Untertiteloptionen, Puffer und Netzwerkpfade unterscheiden. Gleichzeitige Wiedergabe erhöht zusätzlich den Druck auf gemeinsam genutzten Speicher und das Netzwerk. Der aussagekräftige Test besteht darin, die Datei unverändert zu lassen und die erste Phase zu ermitteln, die langsamer wird, sobald ein weiterer Client hinzukommt.
Zuerst bestätigen, dass die verzögerte Sitzung weiterhin Direct Play verwendet
Eine Sitzung, die letztendlich flüssig wirkt, kann in den ersten Sekunden zunächst einen anderen Wiedergabepfad aushandeln. Prüfe das Plex-Dashboard während des Starts und nachdem sich der Stream stabilisiert hat, da ein vorübergehendes Remuxing oder Transcoding die Diagnose verändert. Direct Play sollte bedeuten, dass die ursprünglichen Streams ohne serverseitige Videokonvertierung bereitgestellt werden.
Die Direct-Play-Kompatibilität hängt davon ab, ob der Client die Medien akzeptiert und ob der Bereitstellungspfad die erforderliche Datenrate aufrechterhalten kann. Eine gemischte Geräteflotte kann daher bereits vor einem durch Gleichzeitigkeit verursachten Hardwareproblem unterschiedliches Startverhalten mit demselben Server zeigen.
Wenn der verzögerte Client tatsächlich transcodiert, solltest du das Problem nicht länger als verzögertes Direct Play bezeichnen, sondern untersuchen, warum die Konvertierung ausgewählt wurde. Wenn die Sitzung von Anfang an Direct Play bleibt, fahre mit der Untersuchung der Clienteinstellungen, der anfänglichen Pufferung, der Speicherauslese und der Netzwerküberlastung fort.
Qualitätseinstellungen des Clients können die Wiedergabeentscheidung verzögern oder ändern
Entfernte und gerätespezifische Qualitätseinstellungen sind Teil der Anfrage, die den Server erreicht. Ein Client, der unterhalb der Originalqualität konfiguriert ist, kann eine Konvertierung erzwingen, selbst wenn das Gerät die Quelldatei unterstützt. Ein anderer Client desselben Kontos kann dagegen Originalqualität anfordern und Direct Play verwenden.
Eine Prüfung der Clientkonfiguration ist besonders aussagekräftig, da Einstellungen für die Remote-Qualität bestimmen können, ob Plex die Originaldatei sendet oder einen Stream mit niedrigerer Bitrate erstellt. Bei gleichzeitiger Nutzung kann ein falsch konfigurierter Client eine rechenintensive Konvertierung hinzufügen, die indirekt mit Sitzungen konkurriert, die weiterhin Direct Play verwenden.
Vergleiche das verzögerte Gerät mit einem schnellen Gerät unter Verwendung desselben Kontos, derselben Datei, derselben Audiospur, desselben Untertitelstatus und derselben Qualitätseinstellung. Wenn die Anpassung dieser Einstellungen die Verzögerung beseitigt, hat die gleichzeitige Nutzung durch unterschiedliche Clients einen Unterschied in den Anfragen sichtbar gemacht und keine serverweite Leistungsgrenze.
Die anfängliche Pufferung macht die Netzwerklatenz vor der kontinuierlichen Wiedergabe sichtbar
Auch Direct Play erfordert, dass der Client den Stream öffnet, genügend Daten für einen sicheren Start empfängt und seinen Puffer vor der Wiedergabeposition hält. Ein Pfad mit höherer Latenz oder schwankendem Datendurchsatz kann sich beim Start daher langsam anfühlen, selbst wenn die durchschnittliche Bandbreite nach dem Aufbau des Streams ausreicht.
Einstellungen für Remote-Qualität und Verbindung können die Wiedergabe verzögern oder stören, selbst wenn die nominelle Bandbreite großzügig erscheint. Die verschiedenen Plex-Apps weisen jeweils eigenes Verhalten bei Qualität und Bereitstellung auf. Untersuche daher zuerst die Clientanfrage, bevor du die Serverkapazität veränderst.
Teste Startzeit und kontinuierliche Bitrate getrennt voneinander. Wenn der verzögerte Client aufholt und anschließend problemlos läuft, während bereits ein anderer Client aktiv ist, deutet das eher auf anfängliche Pufferung oder Pfadverzögerung als auf eine dauerhaft unzureichende Serverkapazität hin.
Audio, Untertitel und Containerverarbeitung können eine clientabhängige Verzögerung verursachen
Ein Client kann das Video akzeptieren, aber eine andere Audiospur, eine bestimmte Untertitelverarbeitung oder einen anderen Containerpfad benötigen. Dadurch kann Direct Stream oder eine geringfügige Audiokonvertierung ausgelöst werden, was leicht übersehen wird, wenn der Nutzer nur auf das Bild achtet. Änderungen an der Spur können außerdem eine neue Anfrage und eine erneute Pufferungsphase auslösen.
Bei einem Samsung-spezifischen Fehlerpfad änderte sich die Wiedergabe, wenn Audiokonvertierung und Untertitel gleichzeitig aktiv waren, obwohl das zugrunde liegende Video unverändert blieb. Entscheidend ist die Clientabhängigkeit und nicht die Behauptung, dass jedes Untertitelformat dieselbe Verzögerung verursacht.
Wiederhole den Starttest mit deaktivierten Untertiteln und einer breit kompatiblen Audiospur. Wenn die Verzögerung einer bestimmten Spur oder Untertitelauswahl folgt, solltest du die Serverhardware erst dann in die Erklärung einbeziehen, wenn dieser clientabhängige Pfad geklärt ist.
Gleichzeitige Nutzung legt die langsamste gemeinsam genutzte Bereitstellungsstufe offen
Wenn mehrere Direct-Play-Sitzungen gleichzeitig laufen, muss der Server weiterhin Medien öffnen, Quelldaten lesen, mehrere TCP-Streams senden und Metadaten- oder Coveranfragen bedienen. Eine Speicherwarteschlange oder ein gemeinsam genutzter Uplink kann die Startverzögerung erhöhen, bevor sie stark genug wird, um offensichtliche Pufferprobleme während der kontinuierlichen Wiedergabe zu verursachen.
Selbst wenn der Server die Originalmedien sendet, ist der Client weiterhin auf einen Wiedergabepuffer angewiesen, der kurze Schwankungen bei der Bereitstellung während des Starts und der Wiedergabe auffängt. Eine einzelne Zahl für den durchschnittlichen Datendurchsatz kann daher nicht jede Startverzögerung bei unterschiedlichen Clients erklären.
Wenn die Wiedergabe von einem verzögerten Start zu wiederholten Pausen übergeht, solltest du Startverzögerung und Pufferung voneinander trennen, bevor du Änderungen am Server vornimmst. Die Ursache liegt in der frühesten veränderten Bedingung: Anfragekompatibilität, Clientpuffer, Medienöffnung oder Druck auf die gemeinsam genutzte Bereitstellung.
Tech- & KI-Zentrum
Mehr zum Lesen

Was ist der Plex-Zustand, und welche Teile müssen erhalten bleiben?
Der persistente Plex-Zustand umfasst die Informationen, die das Servererlebnis über Neustarts und Neuaufbauten hinweg erhalten; Medien und temporäre Transkodierungsdaten erfüllen separate Aufgaben.

Wie handhabt Plex die Authentifizierung bei lokalen und Remote-Sitzungen?
Die Plex-Authentifizierung beginnt mit der Identität des Servers und des Kontos. Anschließend bestimmen lokale oder entfernte Netzwerkpfade die Erreichbarkeit und das Verhalten der sicheren...

Warum kann die Plex-Suche langsamer werden, wenn die Bibliotheksdaten wachsen?
Das Wachstum der Bibliothek allein ist nicht die Diagnose. Prüfe zunächst die Abfragestruktur, Indizes, den Cache-Zustand, die Speicherlatenz und die Schreibaktivität, bevor du die...

