Comment Jellyfin coordonne Kodi avec son service central
Jellyfin coordonne Kodi en conservant l’autorité du serveur, tandis qu’un module complémentaire s’authentifie, synchronise les métadonnées, reçoit les mises à jour et résout chaque demande de lecture.
Un boîtier Kodi peut donner l’impression d’utiliser une bibliothèque locale native, même si Jellyfin reste responsable des utilisateurs, de l’état de visionnage, des métadonnées et des règles d’accès. Cette expérience repose sur deux modèles d’intégration différents : Jellyfin for Kodi copie les données de catalogue sélectionnées dans Kodi, tandis que JellyCon interroge le serveur de manière plus dynamique. La lecture peut ensuite passer par Jellyfin ou utiliser des chemins réseau traduits, ce qui modifie à la fois la cohérence et les exigences réseau.
Le serveur reste la source de l’identité et de l’état
Kodi s’authentifie en tant qu’utilisateur Jellyfin et ne reçoit que les bibliothèques et les actions autorisées pour ce compte. Le serveur reste responsable de l’identité des médias, des décisions relatives aux métadonnées, de la progression de visionnage et de la visibilité des sessions, même lorsque l’interface du client est native à Kodi.
Une explication destinée aux utilisateurs sur la synchronisation des métadonnées Kodi distingue le module complémentaire à synchronisation complète de la navigation plus légère, de type module complémentaire, de JellyCon. La différence tient à l’endroit où l’état du catalogue est matérialisé.
Cette séparation des responsabilités empêche Kodi de devenir un second gestionnaire de médias indépendant, mais elle crée une obligation de synchronisation. Les entrées locales de Kodi doivent continuer à correspondre à des identifiants d’éléments Jellyfin stables.
La synchronisation transforme les changements du serveur en entrées locales
Jellyfin for Kodi copie d’abord les métadonnées sélectionnées dans la base de données locale de Kodi, puis utilise des mécanismes de mise à jour au démarrage et en temps réel pour maintenir la cohérence. Le modèle fondé sur une file d’attente permet à Kodi de demander les changements intervenus depuis sa dernière position connue, au lieu de reconstruire toute la bibliothèque à chaque fois.
Les retours d’expérience sur l’intégration de Kodi avec Jellyfin montrent que les données de la bibliothèque apparaissent dans les vues natives de Kodi après la synchronisation. Cette matérialisation locale explique pourquoi la navigation peut sembler instantanée, même lorsque le serveur est distant sur le réseau local.
La limite concerne la propriété de la base de données : les autres outils qui modifient cette même base de données Kodi peuvent entrer en conflit avec la représentation synchronisée. Une navigation locale rapide ne signifie pas que Kodi est devenu la source de référence des métadonnées.
Le mode de lecture choisit les URL du serveur ou les chemins natifs
En mode module complémentaire, Jellyfin résout la lecture et peut appliquer ses décisions habituelles de diffusion. En mode natif, Kodi accède directement aux chemins SMB ou NFS, après que le remplacement de chemin a traduit la vue du système de fichiers du serveur en un emplacement réseau accessible au client.
Les discussions sur la lecture par chemin natif mettent en évidence le mécanisme clé : les fichiers multimédias bruts peuvent contourner le chemin de diffusion de Jellyfin, tandis que la coordination des métadonnées reste active. Cela peut réduire l’intervention du serveur, mais ajoute des exigences concernant les autorisations des partages et la cohérence des chemins.
Le mode natif n’est donc pas universellement plus rapide. Il n’est utile que lorsque Kodi peut accéder de manière fiable aux mêmes fichiers et les décoder lui-même ; les clients distants ou les montages incohérents privilégient généralement le chemin géré par le serveur.
Une liste de contrôle de coordination pour éviter les comportements en divergence
La coordination échoue lorsque les identités, les chemins ou les positions de mise à jour divergent. Reconstruire Kodi sans réinitialiser l’état de synchronisation, modifier les chemins Jellyfin sans mettre à jour les remplacements ou mélanger des outils Kodi indépendants qui écrivent dans la base de données peuvent laisser des entrées obsolètes, même si les deux applications continuent de se lancer.
Le modèle de capacités du client plus général explique pourquoi la lecture dans Kodi peut encore différer de celle d’autres clients après la synchronisation des métadonnées. La prise en charge du décodage par Kodi et le chemin choisi restent des variables distinctes. Un autre rapport de terrain recommande également d’utiliser la synchronisation de Kodi au démarrage, plutôt que de supposer que le symptôme visible révèle le goulot d’étranglement.
Après toute modification, validez quatre contrats : le profil Kodi correspond à l’utilisateur Jellyfin prévu ; un nouvel élément arrive via la synchronisation au démarrage ou en temps réel ; l’état de visionnage est renvoyé au serveur ; et un fichier de test est résolu par le module complémentaire ou le chemin natif sélectionné, sans solution de repli.
Produits recommandés
Centre Tech & IA
Plus à lire
Pourquoi les performances de Jellyfin diffèrent sur le réseau local et les connexions à distance
Le serveur peut être identique, mais l’accès à distance modifie le budget réseau et entraîne souvent une décision différente concernant la diffusion ou le...
Jellyfin fonctionne-t-il de manière fiable derrière un CGNAT ou un double NAT ?
Le serveur multimédia reste fonctionnel ; le problème non résolu consiste à créer, via la traduction d’adresses, un chemin accessible et sécurisé offrant un...
Comment la latence du réseau affecte la lecture HDR de Jellyfin avec des sous-titres
La lecture de sous-titres HDR associe la transmission réseau au rythme de conversion, de sorte que la gigue et le délai aller-retour peuvent révéler...
