Warum puffert Jellyfin auf einem Heimserver?

Jellyfin puffert, wenn ein Teil des Wiedergabepfads nicht schneller liefern, konvertieren oder dekodieren kann, als die Zeitleiste voranschreitet. Videotranskodierung ist eine häufige Ursache, aber nicht die einzige. Ein Stream kann auch wegen Client-Codec-Limits, Untertitelverarbeitung, instabilem WLAN, unzureichender Upload-Bandbreite bei entfernten Nutzern, Speicherengpässen oder einem Transkodierungsverzeichnis, das keine weiteren temporären Daten aufnehmen kann, stocken.

Der schnellste Weg, den Engpass zu finden, ist, den aktuellen Wiedergabemodus zu prüfen, bevor Sie Hardwareeinstellungen ändern. Vergleichen Sie dann, ob das Problem jede Datei betrifft, nur 4K- oder HDR-Medien, einen Client, entfernte Nutzer, Wiedergabe mit Untertiteln oder mehrere gleichzeitige Streams.

Überprüfen Sie den Wiedergabemodus, bevor Sie etwas ändern

Öffnen Sie das Jellyfin-Dashboard, während das betroffene Video abgespielt wird, und überprüfen Sie die aktive Sitzung. So lässt sich feststellen, ob der Server die Originaldatei liefert oder gerade einen Teil davon konvertiert.

Jellyfin unterteilt die Wiedergabe in vier Wiedergabepfade mit zunehmend höherer Serverbelastung: Direct Play, Remux, Direct Stream und Video-Transkodierung. Direct Play sendet das Originalmedium mit fast keiner Verarbeitung. Remux ändert den Container, Direct Stream konvertiert Audio und behält das Video bei, und Transcode kodiert den Videostream neu.

Dieses erste Ergebnis ändert die gesamte Fehlerbehebungsrichtung. Wenn Direct Play puffert, beginnen Sie mit Netzwerk, Speicher, Client und Mediendatei. Wenn die Videotranskodierung puffert, prüfen Sie, warum die Konvertierung angefordert wurde und ob der Server die gesamte Pipeline schnell genug abschließen kann.

Finden Sie heraus, warum Jellyfin eine Transkodierung angefordert hat

Eine Datei wird nicht einfach deshalb direkt abgespielt, weil der Client seinen Videocodec unterstützt. Jellyfin bewertet die vollständige Kombination aus Container, Videocodec, Codec-Profil, Farbtiefe, Auflösung, Audioformat, Kanalbelegung, Untertiteln, Bitrate und Wiedergabebeschränkungen des Clients.

Beispielsweise unterstützt der Client möglicherweise HEVC-Video, aber nicht die enthaltene TrueHD-Audiospur. Ein anderer Client kann beide Streams dekodieren, aber das ausgewählte Untertitelformat nicht darstellen. Diese Unterschiede können dieselbe Datei auf einem Gerät als Direct Play, auf einem anderen als Audiokonvertierung und im Browser als vollständige Videotranskodierung erscheinen lassen.

Notieren Sie den Wiedergabegrund, bevor Sie Einstellungen ändern. Testen Sie auch eine andere Audiospur, deaktivieren Sie Untertitel und spielen Sie dieselbe Datei über einen anderen Jellyfin-Client ab. Diese kontrollierten Tests sind hilfreicher als das Aktivieren aller Codec-Optionen im Transkodierungsmenü.

Software-Transkodierung kann einen kleinen Server überlasten

Software-Transkodierung verwendet die CPU, um die Quelle zu dekodieren, Filter anzuwenden, das Bild zu skalieren und in Echtzeit einen neuen Stream zu kodieren. Ein leistungsschwacher Prozessor kann eine 1080p-Konvertierung bewältigen, aber bei 4K HEVC, 10-Bit-Video oder HDR versagen.

Wenn die Konvertierung nicht mit der Wiedergabe Schritt halten kann, verbraucht der Client schließlich die gepufferten Videosegmente und pausiert. Die CPU-Auslastung kann nahe am Maximum bleiben, während Jellyfin wiederholt versucht, genügend Daten vor der aktuellen Position aufzubauen.

Wenn der Server über eine unterstützte integrierte oder dedizierte GPU verfügt, ist eine korrekt konfigurierte Hardwarebeschleunigung in der Regel nützlicher als das Ändern der FFmpeg-Thread-Anzahl. Hat der Server keinen kompatiblen Encoder, kann das Reduzieren der angeforderten Auflösung oder Bitrate bestätigen, dass die Transkodierungskapazität der begrenzende Faktor ist.

Hardwarebeschleunigung ist eine mehrstufige Pipeline

Die Auswahl von Intel Quick Sync, VA-API, NVIDIA NVENC oder AMD AMF im Dashboard garantiert nicht, dass jeder Teil der Konvertierung auf der GPU ausgeführt wird.

Eine Jellyfin-Transkodierung kann Dekodierung, Entflechtung, Skalierung, Formatkonvertierung, HDR-Tonemapping, Untertitel-Einbrennen und Kodierung umfassen. Jellyfin weist darauf hin, dass einige Stufen aufgrund von Hardware-, Treiber- oder Softwareeinschränkungen auf der CPU verbleiben können. Teilweise Beschleunigung kann daher auch bei sichtbarer GPU-Aktivität eine hohe CPU-Auslastung verursachen.

Überprüfen Sie den gesamten Vorgang und nicht nur das Vorhandensein einer GPU. Erzwingen Sie eine vorhersehbare Transkodierung, beobachten Sie die Video-Dekodier- und Kodier-Engines, prüfen Sie den FFmpeg-Befehl und suchen Sie nach Filtern, die auf Software zurückgefallen sind.

Aktivieren Sie keine Dekodierformate, die Ihre GPU nicht verarbeiten kann

Die Seite zur Hardware-Beschleunigung ermöglicht Administratoren die Auswahl von Videoformaten, die Jellyfin versuchen kann, über die GPU zu dekodieren. Das Aktivieren eines nicht unterstützten Formats fügt der Hardware diese Fähigkeit nicht hinzu.

Wenn die GPU das genaue Codec-Profil oder die Bit-Tiefe nicht dekodieren kann, kann Jellyfin auf Software-Dekodierung zurückfallen oder den Hardware-Pfad nicht initialisieren. Deshalb kann eine HEVC-Datei funktionieren, während eine andere unerwartet hohe CPU-Auslastung verursacht.

Bestätigen Sie die GPU-Generation und unterstützte Profile, und aktivieren Sie nur die Formate, die tatsächlich verarbeitet werden können. Testen Sie gewöhnliche H.264-, HEVC Main 10- und HDR-Dateien separat, anstatt alle 4K-Medien als eine einzige Arbeitslast zu behandeln.

Docker muss Zugriff auf die GPU erhalten

Eine vom Host-Betriebssystem erkannte GPU ist nicht automatisch innerhalb eines Jellyfin-Containers verfügbar. Der Container benötigt außerdem die korrekte Gerätezuordnung, Laufzeit, Treiber, Gruppen und Berechtigungen.

Bei Intel- und AMD-GPUs unter Linux stellt der Host üblicherweise Render-Geräte unter /dev/dri bereit. Der Container-Benutzer muss auf das relevante Render-Gerät zugreifen können. NVIDIA-Konfigurationen erfordern den Host-Treiber und eine geeignete Container-Laufzeit. Praktische Docker-Prüfungen umfassen die Überprüfung des Render-Geräts, dessen Zuordnung zum Container und das Hinzufügen der korrekten Render-Gruppen-GID.

Lassen Sie den Container nicht dauerhaft im privilegierten Modus. Dieser kann kurzzeitig verwendet werden, um zu bestätigen, dass das zugrundeliegende Problem der Gerätezugriff ist, aber die endgültige Bereitstellung sollte nur die erforderlichen GPU-Ressourcen und Berechtigungen freigeben.

Überprüfen Sie die GPU-Aktivität während einer echten Transkodierung

Ein erfolgreicher Containerstart beweist nicht, dass die Hardware-Transkodierung funktioniert. Jellyfin kann normal laufen, die Bibliothek scannen und Dateien direkt abspielen, ohne nutzbaren Zugriff auf die GPU zu haben.

Erzwingen Sie eine Transkodierung, indem Sie vorübergehend eine niedrigere Client-Qualität als die Quelle wählen. Überwachen Sie auf Intel-Systemen die Video-Engines mit einem Tool wie intel_gpu_topUntersuchen Sie auf NVIDIA-Systemen aktive Prozesse und Encoder-Aktivitäten mit nvidia-smiÜberprüfen Sie auch, ob die CPU-Auslastung im Vergleich zur Software-Transkodierung sinkt.

Wenn keine GPU-Aktivität vorliegt, überprüfen Sie das zugeordnete Gerät, den Container-Benutzer, die Render-Gruppenmitgliedschaft, die Hardware-Beschleunigungsmethode und das FFmpeg-Protokoll. Wenn die GPU aktiv ist, die Wiedergabe jedoch weiterhin langsam bleibt, kann eine andere Pipeline-Stufe noch in Software ausgeführt werden.

Untertitel können ein vollständiges Videotranscoding auslösen.

Ein häufiges Symptom ist eine flüssige Wiedergabe, bis Untertitel aktiviert werden. Dies tritt oft bei bildbasierten Untertiteln oder gestylten Formaten auf, die der gewählte Client nicht direkt rendern kann.

Wenn Jellyfin Untertitel ins Bild einbrennen muss, dekodiert es jeden Frame, rendert die Untertitel-Ebene und kodiert einen neuen Videostream. Das kann eine ansonsten wenig belastete Direct-Play-Sitzung zu einem der aufwendigsten Wiedergabepfade des Servers machen.

Deaktiviere Untertitel und spiele dieselbe Szene erneut ab. Wenn das Puffern verschwindet, probiere eine textbasierte Untertitelspur wie SRT, teste einen anderen Client oder überprüfe, ob der gewählte Hardwarepfad die umgebenden Dekodier-, Filter- und Kodieroperationen beschleunigen kann.

HDR-Tonemapping kann anspruchsvoller sein als normales Transcoding.

Wenn 1080p- und gewöhnliche 4K-SDR-Medien korrekt abgespielt werden, HDR-Inhalte auf einem SDR-Client jedoch puffern, ist Tonemapping ein wahrscheinlicher Grund.

Der Server muss möglicherweise eine 10-Bit-HDR-Quelle dekodieren, deren Farb- und Helligkeitsbereich für SDR konvertieren, skalieren und einen neuen Videostream kodieren. Ein System, das normales H.264-Transcoding beherrscht, kann diese vollständige Aufgabe möglicherweise nicht in Echtzeit per Software ausführen.

Teste dieselbe HDR-Datei auf einem HDR-fähigen Client, erzwinge dann ein SDR-Transcoding und vergleiche CPU- und GPU-Aktivität. Hardwareunterstützung für HEVC-Dekodierung beweist nicht automatisch, dass die gewählte Tonemapping-Methode vollständig beschleunigt wird.

Der Client bestimmt einen Großteil des Wiedergabepfads.

Jellyfin kann eine Datei in einem Desktop-Mediaplayer direkt abspielen, während sie im Browser oder auf einem Fernsehgerät transkodiert wird. Dieser Unterschied bedeutet nicht, dass sich die Serverkonfiguration zwischen den Sitzungen geändert hat.

Jeder Client meldet seine unterstützten Codecs, Container, Audioformate, Untertitel, Auflösungen und Bitratenbegrenzungen. Ein leistungsfähigerer Player kann Konvertierungen vermeiden, während ein eingeschränkter Player möglicherweise eine Audiokonvertierung, Remuxing oder vollständiges Videotranscoding benötigt.

Teste dieselbe Datei, Audiospur, Untertitelspur und Netzwerkverbindung auf zwei Clients. Wenn das Problem bei einem Client auftritt, untersuche die Wiedergabefähigkeiten und App-Einstellungen dieses Geräts, bevor du den Server änderst.

Direct Play kann trotzdem puffern.

Direct Play eliminiert die Videokonvertierung als Hauptengpass, beweist jedoch nicht, dass alle anderen Teile des Pfads einwandfrei funktionieren.

Das NAS muss die Medien weiterhin lesen, das Netzwerk muss sie kontinuierlich liefern, und der Client muss sie dekodieren und wiedergeben. Spitzen mit hoher Bitrate, instabiles WLAN, eine langsame Client-Oberfläche, Wiederholungen bei Speicherfehlern oder ein unterdimensionierter Player können einen ansonsten direkten Stream unterbrechen.

Kopieren Sie die problematische Datei auf den Client und spielen Sie sie lokal ab. Wenn die lokale Wiedergabe ebenfalls ruckelt, untersuchen Sie die Mediendatei oder den Client-Decoder. Wenn die lokale Kopie funktioniert, während Jellyfin Direct Play puffert, konzentrieren Sie sich auf das Netzwerk und den Server-Speicherpfad.

Testen Sie den tatsächlichen LAN-Pfad statt eines Internet-Geschwindigkeitstests

Ein schnelles Internetergebnis misst nicht den Pfad vom Jellyfin-Server zu einem Fernseher, Telefon oder Streaming-Box im Haus. Es zeigt auch kein Wi-Fi-Jitter, Paketverlust, Mesh-Backhaul-Stau oder eine langsame Geräte-Schnittstelle an.

Eine nützliche lokale Diagnose vergleicht den nachhaltigen Datei-Kopierdurchsatz, einen kabelgebundenen Client, eine niedrigere Bitrate-Codierung und die ursprüngliche Datei mit hoher Bitrate. Praktische lokale Streaming-Checks umfassen auch das Testen von Ethernet, die Überprüfung, ob der Client eine Transkodierung erzwingt, und das Verschieben schwerer Hintergrundaufgaben außerhalb der Betrachtungszeiten.

Achten Sie auf eine nachhaltige Leistung statt auf den höchsten Wert, der nur für wenige Sekunden angezeigt wird. Video mit großen Bitraten-Spitzen benötigt genügend Spielraum, um kurze Netzverzögerungen zu überstehen, ohne den Client-Puffer zu erschöpfen.

Remote-Puffern hat normalerweise eine andere Ursache

Wenn dasselbe Medium zu Hause korrekt abgespielt wird, aber über eine externe Verbindung puffert, sind die Upload-Bandbreite des Servers und die entfernte Route die Hauptverdächtigen.

Die nutzbare Rate wird durch die Upload-Geschwindigkeit der Heimverbindung, die Download-Geschwindigkeit des entfernten Clients, VPN- oder Reverse-Proxy-Overhead, konkurrierenden Haushaltsverkehr und die Stream-Bitrate begrenzt. Ein großes Remux kann die verfügbare Upload-Kapazität überschreiten, obwohl es im LAN perfekt Direct Play abspielt.

Reduzieren Sie vorübergehend die Wiedergabequalität aus der Ferne. Wenn das das Puffern behebt, stellen Sie eine nachhaltige Remote-Bitrate ein oder verwenden Sie Hardware-Transkodierung, um einen kleineren Stream zu erzeugen. Behandeln Sie die niedrigere Einstellung als Hinweis auf eine Bandbreitenbegrenzung, nicht als Beweis dafür, dass die Originaldatei defekt ist.

Speicher fällt eher bei gleichzeitiger Arbeit aus

Eine gesunde Festplatte kann normalerweise einen normalen Filmstream ohne Probleme lesen. Die Speicherung wird verdächtiger, wenn die Wiedergabe mit Downloads, Backups, Bibliotheksscans, Miniaturbildgenerierung, Paritätsoperationen, Prüfungen oder mehreren Benutzern gleichzeitig erfolgt.

Diese Aufgaben erzeugen konkurrierende Lese-, Schreib- und Suchvorgänge. Eine Festplatte kann in einem Benchmark eine akzeptable sequenzielle Geschwindigkeit zeigen und dennoch unter gemischter Aktivität eine hohe Latenz entwickeln.

Überwachen Sie Auslastung und Latenz während des Pufferens. Pausieren Sie Downloads und Wartungsaufgaben, und spielen Sie dann dieselbe Datei erneut ab. Halten Sie die Jellyfin-Datenbank, Metadaten und den Cache möglichst auf latenzarmen Speichern, während große Mediendateien auf kapazitätsorientierten Festplatten verbleiben können.

Ein volles Transcode-Verzeichnis kann die Wiedergabe stoppen

Transkodiertes Video wird als temporäre Segmente geschrieben, bevor der Client es konsumiert. Wenn das zugewiesene Dateisystem, SSD, RAM-Disk oder Docker-Volume nicht genügend freien Speicherplatz hat, kann FFmpeg keine neuen Segmente mehr erzeugen.

Ein früheres Jellyfin-Problem dokumentierte, wie die Wiedergabe nur bis zum letzten Segment fortgesetzt werden konnte, das vor dem Füllen des Transcode-Verzeichnisses erstellt wurde. Der Bericht ist alt und geschlossen, aber das Symptom bleibt ein nützlicher Grund, den Speicherplatz zu prüfen, wenn ein transkodierter Stream nach einigen Minuten stoppt.

Überprüfen Sie den freien Speicherplatz, die Verfügbarkeit von Inodes, die Container-Zuordnung, Schreibrechte und Kapazitätsgrenzen des Transcode-Pfads. Seien Sie besonders vorsichtig bei kleinen RAM-Disks oder temporären Dateisystemen: Die Nutzung von Speicher kann die Speicherlatenz reduzieren, aber eine zu geringe Begrenzung kann zu einem abrupten Wiedergabefehler führen.

Eine einzelne Problemdatei weist meist auf die Mediendatei hin

Wenn viele Dateien mit ähnlicher Auflösung und Bitrate korrekt abgespielt werden, ist es unwahrscheinlich, dass eine einzelne fehlerhafte Datei beweist, dass der gesamte Server unterdimensioniert ist.

Die Datei kann ein ungewöhnliches Codec-Profil, beschädigte Frames, ein nicht unterstütztes Audio-Layout, eine Bilduntertitelspur, falsche Zeitstempel oder einen extremen Bitratenpeak enthalten. Eine Staffel einer Serie kann auch anders kodiert sein als die anderen.

Testen Sie eine andere Audiospur, deaktivieren Sie Untertitel, prüfen Sie die Medieninformationen und vergleichen Sie die Datei mit einem anderen Titel, der denselben Codec verwendet. Ein einfaches Remuxen in einen neuen Container kann helfen festzustellen, ob der Container oder Zeitstempel betroffen sind, ohne das gesamte Video neu zu kodieren.

Mehrere Streams zeigen gemeinsame Ressourcenbeschränkungen auf

Ein Heimserver kann einen Stream problemlos verarbeiten und beginnt erst mit dem Puffern, wenn ein weiterer Nutzer die Wiedergabe startet. Vergleichen Sie den Wiedergabemodus jeder aktiven Sitzung, bevor Sie annehmen, dass allein das Netzwerk verantwortlich ist.

Mehrere Direct-Play-Sitzungen erhöhen hauptsächlich die Speicher- und Netzwerklast. Mehrere Video-Transcodierungen konkurrieren zudem um GPU-Encoding-Kapazität, CPU-Filter, Speicherbandbreite und Speicherplatz im Transcode-Verzeichnis.

Testen Sie eine Sitzung und fügen Sie dann Streams einzeln hinzu, während Sie CPU-, GPU-, Festplatten- und Netzwerkauslastung beobachten. So erkennen Sie, ob die praktische Grenze die Anzahl der Konvertierungen, die aggregierte Medien-Bitrate oder gemischte Speicheraktivität ist.

Lesen Sie das FFmpeg-Protokoll, bevor Sie Jellyfin neu installieren.

Das Server-Dashboard zeigt an, welche Art von Wiedergabe stattfindet, während das entsprechende FFmpeg-Protokoll erklärt, wie Jellyfin versucht hat, die Datei zu verarbeiten.

Achten Sie auf Fehler bei der Initialisierung von Hardware-Geräten, Berechtigungsfehler, nicht unterstützte Profile, Software-Fallback, Untertitelfilter, Tonemapping-Filter, Ein-/Ausgabefehler, Prozess-Abbruchcodes und Speicherplatzfehler.

Erfassen Sie das Protokoll aus der genauen Sitzung, die puffert. Ein Protokoll von einem nicht verwandten Direct Play oder erfolgreicher Transkodierung kann zu falschen Schlussfolgerungen führen. Eine Neuinstallation des Servers behebt selten eine Client-Codec-Grenze, ein nicht zugängliches GPU-Gerät oder ein volles temporäres Verzeichnis.

Verwenden Sie das Symptom, um den nächsten Test auszuwählen.

Folgen Sie dieser Fehlerbehebungsreihenfolge.

1. Reproduzieren Sie das Problem mit derselben Datei und demselben Client.
2. Öffnen Sie das Jellyfin-Dashboard und notieren Sie den Wiedergabemodus.
3. Notieren Sie den angegebenen Grund für die Transkodierung oder Kompatibilität.
4. Deaktivieren Sie Untertitel und testen Sie eine andere Audiospur.
5. Spielen Sie dieselbe Datei über einen anderen Client ab.
6. Überprüfen Sie die CPU- und GPU-Aktivität während der betroffenen Sitzung.
7. Öffnen Sie das passende FFmpeg-Protokoll.
8. Überprüfen Sie den Speicherplatz und die Schreibberechtigungen des Transkodierungsverzeichnisses.
9. Testen Sie die anhaltende LAN-Durchsatzrate oder die Upload-Kapazität aus der Ferne.
10. Pausieren Sie Downloads, Backups, Scans und Speicherwartung.
11. Vergleichen Sie die Problemdatei mit ähnlichen Medien.
12. Erwägen Sie neue Hardware erst, wenn die Beweise eine Rechenbegrenzung zeigen.

Diese Reihenfolge verhindert, dass nicht zusammenhängende Änderungen die ursprüngliche Ursache verschleiern. Ändern Sie jeweils nur eine Variable und spielen Sie dieselbe Szene erneut ab, damit die Ergebnisse vergleichbar bleiben.

Fazit

Jellyfin-Pufferung bedeutet nicht automatisch, dass der Heimserver eine schnellere CPU benötigt. Beginnen Sie mit dem aktiven Wiedergabemodus, da Direct Play und Videotranskodierung auf unterschiedliche Systembereiche hinweisen.

Bei transkodierten Sitzungen gilt es zu klären, warum eine Konvertierung erforderlich ist, die vollständige Hardwarebeschleunigungspipeline zu überprüfen, ohne Untertitel zu testen, HDR-Tonemapping zu inspizieren und sicherzustellen, dass der Transkodierpfad genügend beschreibbaren Speicherplatz hat. In Docker sollte die GPU von innen im Container überprüft werden, anstatt sich nur auf die Host-Erkennung zu verlassen.

Bei Direct Play liegt der Fokus auf dauerhaftem Netzwerkdurchsatz, Client-Dekodierung, Speicheraktivität und der einzelnen Mediendatei. Die Kombination aus Wiedergabemodus, Client, Codec, Untertiteln, Ressourcenaktivität und FFmpeg-Protokollen liefert eine zuverlässigere Diagnose als das willkürliche Ändern von Einstellungen oder der Austausch von Hardware.

FAQ

Warum puffert Jellyfin nur, wenn Untertitel aktiviert sind?

Das ausgewählte Untertitelformat erfordert möglicherweise ein Einbrennen. Jellyfin muss dann das Video dekodieren, Untertitel auf jeden Frame rendern und einen neuen Stream kodieren. Versuchen Sie, die Untertitel zu deaktivieren, eine textbasierte Spur auszuwählen oder einen Client zu verwenden, der das Untertitelformat direkt rendern kann.

Warum transkodiert Jellyfin auf einem Gerät, aber verwendet Direct Play auf einem anderen?

Clients unterstützen unterschiedliche Kombinationen von Containern, Videocodecs, Audioformaten, Untertiteltypen, Profilen und Bitraten. Das weniger kompatible Gerät fordert den Server auf, den nicht unterstützten Teil der Datei zu konvertieren.

Wie kann ich bestätigen, dass die Hardwarebeschleunigung von Jellyfin funktioniert?

Erzwingen Sie eine Videotranskodierung und überprüfen Sie dann die GPU-Dekodier- und Kodier-Engines des Servers. Bestätigen Sie außerdem, dass das FFmpeg-Protokoll das erwartete Hardwaregerät verwendet und dass der Container ohne Berechtigungsfehler auf das Gerät zugreifen kann.

Warum puffert Jellyfin, obwohl Direct Play angezeigt wird?

Direct Play entfernt die Videotranskodierung aus dem Pfad, aber das Netzwerk, der Speicher, die Mediendatei und der Client-Decoder können dennoch zu langsam oder instabil sein. Testen Sie die Datei lokal auf demselben Client und vergleichen Sie die Wiedergabe über Kabel und drahtlos.

Sollte Jellyfin eine SSD für das Transkodieren verwenden?

Eine SSD kann die Latenz bei temporären Segmenten reduzieren und ist nützlich für die Jellyfin-Datenbank, Metadaten und den Cache. Die wichtigere Voraussetzung ist jedoch ein Transkodierpfad mit ausreichend Speicherplatz, zuverlässigen Schreibvorgängen und korrekten Berechtigungen. Ein richtig dimensioniertes RAM-Laufwerk kann ebenfalls funktionieren, aber ein zu kleines kann die Wiedergabe stoppen.