Wie erkennt und synchronisiert Jellyfin Änderungen auf verschiedenen Geräten?

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Jellyfin gleicht die meisten geräteübergreifenden Änderungen über einen zentralen Server ab. Dieser erkennt Aktualisierungen der Bibliothek, speichert den gemeinsamen Status und stellt die daraus resultierende Ansicht für die Clients bereit.

Ein Telefon, Fernseher, Browser und Tablet handeln die maßgebliche Wahrheit der Medienbibliothek normalerweise nicht direkt miteinander aus. Sie kommunizieren mit demselben Jellyfin-Server, der die indizierten Bibliotheksmetadaten und benutzerspezifische Daten wie den Wiedergabefortschritt verwaltet. Die Dateisystemerkennung, Wiedergabeaktualisierungen und Client-Aktualisierungen sind separate Phasen, die auf einer serverseitigen Instanz zusammenlaufen. Daher stimmen die Geräte normalerweise überein, sobald der Server die Änderung akzeptiert hat und jeder Client aktualisiert wurde.

Der Server ist die gemeinsame Instanz, nicht die einzelnen Clients

Clients stellen Bibliotheksansichten dar und senden Benutzeraktionen, aber der dauerhaft gemeinsame Katalog befindet sich auf dem Server. Diese Architektur ermöglicht es einem Fernseher und einem Telefon, dasselbe Element zu sehen, ohne die gesamte Datenbank zwischen den Geräten zu kopieren. Jeder Client kann Darstellungsdaten zwischenspeichern, doch der maßgebliche Datensatz für Bibliothekszugehörigkeit und Benutzerfortschritt bleibt zentralisiert.

Ein Medienserver ist normalerweise die maßgebliche Instanz dafür, was tatsächlich verfügbar ist und was von seinen lokalen Benutzern wiedergegeben wurde. Ein nützliches Modell der Datenquelle betrachtet den Medienserver für die Wiedergabe getrennt von portablen Tracking-Systemen. Dieselbe Ausrichtung erklärt auch Jellyfin-Clients: Sie gleichen sich an den Serverstatus an, statt unter gleichrangigen Geräten einen Gewinner zu bestimmen.

Dieses Modell vereinfacht die Zuordnung von Konflikten, weil es einen Ort gibt, an dem akzeptierte Änderungen dauerhaft gespeichert werden. Ein Client kann vorübergehend veraltete zwischengespeicherte Daten anzeigen, wird aber nicht zu einer zweiten gleichwertigen Datenbank, nur weil er noch nicht aktualisiert wurde. Abgleich bedeutet, die Clientansicht wieder an den vom Server akzeptierten Status anzupassen.

Dateisystemänderungen werden durch serverseitige Erkennung zum Bibliotheksstatus

Das Hinzufügen, Ersetzen, Umbenennen oder Entfernen einer Mediendatei ändert zunächst den Speicher, nicht den Jellyfin-Katalog. Der Server muss dieses Dateisystemereignis über einen Scan, einen Überwachungsauslöser oder ein Automatisierungssignal erkennen, den betroffenen Pfad untersuchen und seine indizierte Darstellung aktualisieren. Erst nach diesem Speichervorgang können Clients die neue Bibliotheksansicht erhalten.

Tools für gezielte Automatisierung wie gezielte Bibliotheksaktualisierungen existieren, weil die Erkennung präziser ausgelöst werden kann, als auf einen umfassenden geplanten Scan zu warten. Der architektonische Punkt bleibt unverändert: Ein Datei­ereignis wird zu einer serverseitigen Bibliotheksaktualisierung, bevor es zu einer geräteübergreifenden Änderung der Benutzeroberfläche wird.

Während des Erkennungszeitraums sind Speicher- und Katalogstatus voneinander getrennt. Eine Datei kann auf der Festplatte vorhanden sein, während die Clients sie noch nicht sehen, oder ein indiziertes Element kann kurzzeitig bestehen bleiben, bis seine Entfernung verarbeitet wurde. Die Zeit von der Dateisystemänderung bis zur Aktualisierung des Serverindexes zu messen, ist daher etwas anderes, als zu messen, wie schnell ein Client aktualisiert wird, nachdem der Server die Änderung bereits gespeichert hat.

Der Wiedergabefortschritt wird in denselben serverseitigen Benutzerstatus zurückgeschrieben

Der Wiedergabefortschritt folgt einem anderen Eingabepfad als die Dateisystemerkennung. Die Mediendatei ändert sich nicht, wenn ein Zuschauer Minute vierzig erreicht. Der Client meldet den mit dem authentifizierten Benutzer verknüpften Wiedergabestatus, und der Server speichert diese benutzerspezifische Änderung. Ein anderes Gerät, das mit demselben Konto angemeldet ist, kann später den gemeinsamen Serverstatus abfragen und an der akzeptierten Position fortsetzen.

Deshalb kann Jellyfin den Wiedergabeverlauf geräteübergreifend synchronisieren, ohne eine lokale Fortschrittsdatei direkt zwischen Fernseher und Telefon zu kopieren. Beide Geräte gleichen sich an, weil sie über denselben Benutzerdatensatz auf dem Server lesen und schreiben, nicht weil sie einen Peer-to-Peer-Abgleich durchführen.

Die entscheidende beobachtbare Grenze ist der Zeitpunkt des Schreibvorgangs. Wenn ein Gerät offline geht, bevor seine Fortschrittsaktualisierung den Server erreicht, kann ein anderes Gerät berechtigterweise noch den älteren Serverwert anzeigen. Sobald die Verbindung wiederhergestellt ist, hängt das endgültige Ergebnis davon ab, welche Aktualisierung die Anwendung akzeptiert und in welcher Reihenfolge. Offline gespeicherter lokaler Fortschritt darf nicht mit bereits gespeichertem gemeinsamem Status verwechselt werden.

Clients gleichen sich durch Aktualisierung vom Server ab, nicht durch Zusammenführung untereinander

Nachdem der Server eine Änderung gespeichert hat, benötigen Clients weiterhin eine Aktualisierung, ein Ereignis, eine Navigation oder eine anschließende Anfrage, durch die sie den neuen Status abrufen. Ein Fernseher kann ein veraltetes Poster-Raster im Speicher behalten, während ein Browser die Aktualisierung bereits anzeigt. Diese vorübergehende Abweichung ist ein Problem des Darstellungscaches, solange der Server selbst keine widersprüchlichen Datensätze enthält.

Die Vielfalt der Clients macht diesen Unterschied sichtbar, weil verschiedene Jellyfin-Clients denselben Server mit unterschiedlichen Oberflächen und Wiedergabeverhalten darstellen können. Wenn ein Client veraltet wirkt, während ein anderer aktuell ist, überprüfe zuerst den Serverstatus und aktualisiere oder verbinde den abweichenden Client erneut, bevor du die Abweichung als Datenbankkonflikt behandelst.

Diese Unterscheidung ist bei der Fehlersuche wichtig. Wenn zwei Clients unterschiedliche Werte anzeigen, frage zuerst den Serverstatus ab oder überprüfe ihn. Enthält der Server den erwarteten Wert und ist nur ein Client veraltet, liegt die Ursache wahrscheinlich bei der Aktualisierung oder dem Cache. Fehlt die Änderung auf dem Server selbst, solltest du die Erkennung, Berechtigungen oder den Schreibvorgang untersuchen, bevor du den zweiten Client verantwortlich machst.

Fehlergrenze: Separate Server gleichen ihre Datenbanken nicht automatisch ab

Das Modell der zentralen Instanz gilt innerhalb einer einzelnen Jellyfin-Serverinstanz. Wenn ein Haushalt zwei unabhängige Server betreibt, kann jeder eigene Benutzer, Wiedergabestatus, Metadatenänderungen und Änderungen an der Bibliotheksdatenbank ansammeln. Es gibt keine allgemeine Annahme, dass diese Datenbanken einander erkennen und sicher zusammengeführt werden, nur weil sie auf ähnliche Mediendateien verweisen.

Serverübergreifende Tools wie die explizite Synchronisierung des Wiedergabestatus existieren genau deshalb, weil unabhängige Medienserver einen ausdrücklichen Abgleichmechanismus für gemeinsamen Fortschritt benötigen. Ein solches Tool kann einen definierten Teil des Status synchronisieren, verwandelt jedoch nicht zwei vollständige Jellyfin-Datenbanken in einen transparenten Multi-Master-Cluster.

Dieselbe Grenze gilt für Offline-Geräte. Ein Client kann eine veraltete lokale Ansicht behalten, sollte aber nicht als maßgebliche Datenbank betrachtet werden, die manuell in Jellyfin integriert werden muss. Wenn mehrere Schreiber oder Server ins Spiel kommen, muss festgelegt werden, welcher Status maßgeblich ist, welche Felder synchronisiert werden und wie widersprüchliche Aktualisierungen aufgelöst werden, bevor das Design als „abgeglichen“ bezeichnet werden kann.

Führe einen Abgleichtest in vier Schritten auf zwei Geräten durch

Verwende zwei Clients, die mit demselben Testbenutzer angemeldet sind, sowie ein bekanntes Medienelement. Füge zunächst eine Testdatei hinzu oder benenne sie um und messe die Erkennungszeit des Servers. Bestätige anschließend, dass beide Clients den neuen Katalogstatus nach der Aktualisierung erhalten. Ändere im dritten Schritt den Wiedergabefortschritt auf Client A und bestätige, dass Client B den vom Server akzeptierten Wert erhält. Starte im vierten Schritt den Server neu und überprüfe, ob der gespeicherte Status erhalten bleibt.

Die interne Erklärung zur Konsistenz bei gleichzeitigen Statusänderungen beschreibt die ergänzende Datenbankgrenze: Akzeptierte Schreibvorgänge benötigen Transaktions- und Reihenfolgeregeln, damit überlappende Aktivitäten keine halb abgeschlossenen Aktualisierungen sichtbar machen. Der geräteübergreifende Test ergänzt diese dauerhafte Statusgarantie um die Zeitpunkte von Erkennung und Client-Aktualisierung.

Der Test ist nur dann bestanden, wenn der Server nach jedem Schritt dieselbe beobachtbare maßgebliche Instanz bleibt: Speicheränderungen werden einmal indiziert, beide Clients gleichen sich an dasselbe Bibliotheksergebnis an, der Benutzerfortschritt wird weder dupliziert noch verloren und ein Neustart macht keine gespeicherte Änderung rückgängig. Bleibt eine Abweichung bestehen, ermittle, ob sie bei der Erkennung, beim Speichern auf dem Server, bei der Client-Aktualisierung oder an der Grenze zwischen separaten Servern aufgetreten ist.

Häufig gestellte Fragen

Synchronisieren sich Jellyfin-Clients direkt miteinander?

Normalerweise nicht. Ein Telefon, Fernseher, Browser und Tablet gleichen sich über den Jellyfin-Server ab: Clients senden Aktualisierungen an den Server und lesen später den Serverstatus. Wenn man Clients als gleichrangige Replikate betrachtet, wirken normale Verzögerungen bei der Aktualisierung wie Konflikte, die tatsächlich nicht existieren.

Warum kann ein Jellyfin-Client veraltete Bibliotheksdaten anzeigen?

Der Server kann eine Bibliotheks- oder Wiedergabeänderung bereits gespeichert haben, während ein Client noch eine ältere zwischengespeicherte Ansicht anzeigt. Bestätige den serverseitigen Status über einen anderen Client oder die Weboberfläche und aktualisiere oder verbinde den abweichenden Client erneut, bevor du Erkennungs- oder Datenbankprobleme untersuchst.

Können zwei separate Jellyfin-Server den Wiedergabefortschritt automatisch synchronisieren?

Separate Jellyfin-Server bilden kein automatisches Multi-Master-System für Statusdaten. Wenn derselbe Benutzer seinen Wiedergabeverlauf zwischen unabhängigen Servern mitnehmen soll, verwende einen ausdrücklichen Synchronisierungsablauf mit einer festgelegten Quelle der Wahrheit und teste das Konfliktverhalten, bevor du dich darauf verlässt.

Tech- & KI-Zentrum

Mehr zum Lesen

Warum behält Jellyfin mehr temporäre Daten als erwartet?
Aug 28, 2026

Warum behält Jellyfin mehr temporäre Daten als erwartet?

Temporäre Jellyfin-Daten haben unterschiedliche Verantwortliche und Lebenszyklen. Beurteile ihre Aufbewahrung anhand des Erstellers, ihres Wiederverwendungswerts und des Bereinigungs auslösers, der sie entfernen sollte.

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.