Comment Jellyfin détecte-t-il et synchronise-t-il les modifications entre les appareils ?
Jellyfin réconcilie la plupart des changements entre appareils via un serveur central, qui détecte les mises à jour de la bibliothèque, enregistre l’état partagé et transmet la vue résultante aux clients.
Un téléphone, une télévision, un navigateur et une tablette ne négocient normalement pas directement entre eux la réalité de la bibliothèque multimédia. Ils communiquent avec le même serveur Jellyfin, qui gère les métadonnées indexées de la bibliothèque et l’état propre à chaque utilisateur, comme la progression de lecture. La détection du système de fichiers, les mises à jour de lecture et les actualisations des clients sont des étapes distinctes qui convergent vers une même autorité côté serveur. Les appareils finissent donc généralement par afficher le même état après que le serveur a accepté la modification et que chaque client s’est actualisé.
Le serveur est l’autorité partagée, pas les clients individuels
Les clients affichent les vues de la bibliothèque et transmettent les actions des utilisateurs, mais le catalogue partagé durable se trouve sur le serveur. Cette architecture permet à une télévision et à un téléphone de voir le même élément sans copier l’intégralité de la base de données entre les appareils. Chaque client peut mettre en cache l’état de présentation, mais l’enregistrement faisant autorité pour l’appartenance à la bibliothèque et la progression de lecture de l’utilisateur reste centralisé.
Un serveur multimédia fait normalement autorité concernant ce qui est réellement disponible et ce qui a été lu par ses utilisateurs locaux. Un modèle utile de source de vérité considère le serveur multimédia pour la lecture comme distinct des systèmes de suivi portables. Cette même logique explique le fonctionnement des clients Jellyfin : ils convergent vers l’état du serveur au lieu de choisir un vainqueur parmi les appareils pairs.
Ce modèle simplifie la gestion des conflits, car les modifications acceptées ne deviennent durables qu’à un seul endroit. Un client peut temporairement afficher des données obsolètes mises en cache, mais il ne devient pas une seconde base de données équivalente simplement parce qu’il ne s’est pas encore actualisé. La réconciliation consiste à ramener la vue du client à l’état accepté par le serveur.
Les changements du système de fichiers deviennent l’état de la bibliothèque grâce à la détection côté serveur
L’ajout, le remplacement, le changement de nom ou la suppression d’un fichier multimédia modifie d’abord le stockage, et non le catalogue Jellyfin. Le serveur doit détecter cet événement du système de fichiers au moyen d’une analyse, d’un déclencheur de surveillance ou d’un signal d’automatisation, examiner le chemin concerné et mettre à jour sa représentation indexée. Ce n’est qu’après cet enregistrement que les clients peuvent recevoir la nouvelle vue de la bibliothèque.
Des outils d’automatisation ciblés, comme les mises à jour ciblées de la bibliothèque, existent parce que la détection peut être déclenchée plus précisément qu’en attendant une analyse planifiée générale. Le principe architectural reste inchangé : un événement de fichier devient une mise à jour de la bibliothèque côté serveur avant de devenir une modification de l’interface sur plusieurs appareils.
Cette distinction sépare la réalité du stockage de celle du catalogue pendant la fenêtre de détection. Un fichier peut exister sur le disque alors que les clients ne le voient toujours pas, ou un élément indexé peut rester brièvement présent jusqu’au traitement de sa suppression. Mesurer le délai entre la modification du système de fichiers et la mise à jour de l’index du serveur est donc différent de mesurer la rapidité avec laquelle un client s’actualise après l’enregistrement de la modification par le serveur.
La progression de lecture revient au même état utilisateur côté serveur
La progression de lecture suit un chemin d’entrée différent de celui de la détection du système de fichiers. Le fichier multimédia ne change pas lorsqu’un spectateur atteint la quarantième minute ; le client signale l’état de lecture associé à l’utilisateur authentifié, et le serveur enregistre cette mise à jour propre à l’utilisateur. Un autre appareil connecté au même compte peut ensuite interroger l’état partagé du serveur et reprendre à la position acceptée.
C’est pourquoi Jellyfin peut synchroniser l’historique de lecture entre les appareils et les clients sans copier directement un fichier local de progression entre la télévision et le téléphone. Les deux appareils convergent parce qu’ils lisent et écrivent via le même enregistrement utilisateur sur le serveur, et non parce qu’ils effectuent une réconciliation pair à pair.
La limite observable est le moment de l’écriture. Si un appareil se déconnecte avant que sa mise à jour de progression n’atteigne le serveur, un autre appareil peut légitimement afficher l’ancienne valeur du serveur. Une fois la connexion rétablie, le résultat final dépend de la mise à jour que l’application accepte et de l’ordre dans lequel elle la traite. Une progression locale hors ligne ne doit pas être confondue avec un état partagé déjà enregistré.
Les clients se réconcilient en s’actualisant depuis le serveur, pas en fusionnant leurs données entre eux
Après l’enregistrement d’une modification par le serveur, les clients ont encore besoin d’une actualisation, d’un événement, d’une action de navigation ou d’une requête ultérieure pour récupérer le nouvel état. Une télévision peut conserver en mémoire une grille d’affiches obsolète alors qu’un navigateur affiche déjà la mise à jour. Cette divergence temporaire relève du cache de présentation, sauf si le serveur lui-même contient des enregistrements contradictoires.
La diversité des clients rend cette distinction visible, car les différents clients Jellyfin peuvent présenter le même serveur avec des interfaces et des comportements de lecture différents. Si un client semble obsolète alors qu’un autre est à jour, vérifiez d’abord l’état du serveur, puis actualisez ou reconnectez le client concerné avant de considérer cette différence comme un conflit de base de données.
Cette distinction est importante pour le dépannage. Si deux clients ne concordent pas, consultez ou inspectez d’abord l’état du serveur. Si le serveur contient la valeur attendue et qu’un seul client est obsolète, l’actualisation ou le cache est probablement en cause. Si le serveur ne contient pas la mise à jour, examinez la détection, les autorisations ou l’événement d’écriture avant d’accuser le second client.
Limite de défaillance : des serveurs distincts ne réconcilient pas automatiquement leurs bases de données
Le modèle d’autorité centrale s’applique à l’intérieur d’une même instance de serveur Jellyfin. Si un foyer utilise deux serveurs indépendants, chacun peut accumuler ses propres utilisateurs, états de lecture, modifications de métadonnées et changements de base de données de bibliothèque. Rien ne garantit que ces bases de données se détecteront et fusionneront correctement simplement parce qu’elles pointent vers des fichiers multimédias similaires.
Des outils interserveurs, comme la synchronisation explicite de l’état de lecture, existent précisément parce que les serveurs multimédias indépendants ont besoin d’un mécanisme de réconciliation explicite pour partager la progression. Cet outil peut synchroniser un sous-ensemble défini de l’état ; il ne transforme pas deux bases de données Jellyfin complètes en cluster transparent multimaître.
La même limite s’applique aux appareils hors ligne. Un client peut conserver une vue locale obsolète, mais il ne doit pas être considéré comme une base de données faisant autorité à fusionner manuellement dans Jellyfin. Lorsque plusieurs rédacteurs ou serveurs sont introduits, définissez l’état faisant autorité, les champs synchronisés et la manière dont les mises à jour contradictoires sont résolues avant de qualifier la conception de « réconciliée ».
Effectuez un test de réconciliation en quatre étapes sur deux appareils
Utilisez deux clients connectés au même utilisateur de test et un élément multimédia connu. Commencez par ajouter ou renommer un fichier de test et mesurez le délai de détection par le serveur. Vérifiez ensuite que les deux clients reçoivent le nouvel état du catalogue après actualisation. Modifiez ensuite la progression de lecture sur le client A et vérifiez que le client B reçoit la valeur acceptée par le serveur. Enfin, redémarrez le serveur et vérifiez que l’état enregistré est conservé.
L’explication interne de la cohérence de l’état concurrent fournit la limite complémentaire de la base de données : les écritures acceptées ont besoin de règles de transaction et d’ordonnancement afin que des activités simultanées ne rendent pas visibles des mises à jour inachevées. Le test entre appareils ajoute à cette garantie d’état persistant les délais de détection et d’actualisation des clients.
Le test est réussi uniquement lorsque le serveur devient la même autorité observable après chaque étape : les changements du stockage sont indexés une seule fois, les deux clients convergent vers le même résultat de bibliothèque, la progression de l’utilisateur n’est ni dupliquée ni perdue, et le redémarrage ne rétablit pas une ancienne valeur à la place d’une mise à jour enregistrée. Si un désaccord persiste, déterminez si la rupture s’est produite lors de la détection, de l’enregistrement côté serveur, de l’actualisation du client ou à la limite entre serveurs distincts.
FAQ
Les clients Jellyfin se synchronisent-ils directement entre eux ?
Normalement, non. Un téléphone, une télévision, un navigateur et une tablette convergent via le serveur Jellyfin : les clients envoient les mises à jour au serveur, puis lisent son état. Traiter les clients comme des répliques paires fait passer de simples délais d’actualisation pour des conflits qui n’existent pas réellement.
Pourquoi un client Jellyfin peut-il afficher des données de bibliothèque obsolètes ?
Le serveur a peut-être déjà enregistré une modification de la bibliothèque ou de la lecture alors qu’un client affiche encore une vue en cache plus ancienne. Confirmez l’état côté serveur depuis un autre client ou l’interface web, puis actualisez ou reconnectez le client concerné avant d’examiner d’éventuels problèmes de détection ou de base de données.
Deux serveurs Jellyfin distincts peuvent-ils synchroniser automatiquement la progression de lecture ?
Des serveurs Jellyfin distincts ne forment pas automatiquement un système d’état multimaître. Si un même utilisateur doit conserver son historique de lecture entre plusieurs serveurs indépendants, utilisez un processus de synchronisation explicite avec une source de vérité définie et testez le comportement en cas de conflit avant de vous y fier.
Produits recommandés
Centre Tech & IA
Plus à lire
Les caméras domestiques peuvent-elles synchroniser les événements sans services horaires cloud ?
Une explication axée sur les mécanismes de l’heure de la caméra sans cloud, ses compromis liés aux ressources partagées, trois FAQ sur la diffusion...
Un service d’IA local peut-il détecter les couches de modèle corrompues avant l’inférence ?
Une explication axée sur les mécanismes de la détection des couches de modèle corrompues, de ses compromis en matière de ressources partagées, de trois...
Un système RAG peut-il être restauré sans régénérer chaque embedding ?
Une explication de la restauration RAG sans réencodage, axée sur le mécanisme, de ses compromis en matière de ressources partagées, trois FAQ sur la...
