Comment vérifier si Jellyfin utilise le fichier de configuration attendu
Oui, vous pouvez vérifier si Jellyfin utilise bien le répertoire de configuration attendu sans vous fier à l’emplacement d’un fichier sur l’hôte. La méthode fiable consiste à déterminer la priorité des chemins de Jellyfin, à examiner les paramètres du processus ou du conteneur en cours d’exécution, puis à confirmer le chemin actif dans les journaux de démarrage avant de modifier un fichier de configuration.
Cela est important après le passage d’une installation par paquet à Docker, le clonage d’un fichier Compose ou la restauration d’un ancien serveur, car plusieurs copies de network.xml, system.xml ou logging.json peuvent exister alors qu’un seul répertoire est actif. Ne modifiez pas toutes les copies jusqu’à la disparition du problème. Identifiez d’abord le répertoire de configuration actif, effectuez une modification réversible, puis vérifiez que Jellyfin signale le même chemin après un redémarrage.
Déterminez d’abord la priorité des chemins de configuration
Commencez par examiner la manière dont Jellyfin a été lancé. L’option de ligne de commande --configdir est prioritaire sur la variable d’environnement JELLYFIN_CONFIG_DIR, tandis que les chemins par défaut de la plateforme ne sont utilisés qu’en l’absence de paramètres prioritaires.
La documentation officielle sur la priorité des chemins de configuration décrit l’ordre de priorité pour les répertoires de données, de configuration, de cache et du Web. Comparez cet ordre avec votre unité de service, l’environnement du conteneur ou la commande de démarrage avant de considérer comme actif un dossier familier de l’hôte.
Si un paramètre prioritaire pointe vers un emplacement inattendu, arrêtez-vous là : le fichier concurrent trouvé sur le disque ne prouve pas que Jellyfin le lit. Corrigez la configuration de lancement ou conservez intentionnellement le chemin actif en le documentant.
Examinez la définition du conteneur ou du service en cours d’exécution
Avec Docker, examinez le conteneur actif plutôt que le seul fichier Compose enregistré sur le disque. L’objet en cours d’exécution indique quelles variables d’environnement et quels montages ont réellement été appliqués lors de la création du conteneur.
La définition du conteneur actif de Docker renvoie des informations de bas niveau sur un conteneur en cours d’exécution. Elles sont utiles pour comparer les valeurs d’environnement et les destinations des montages avec les chemins Jellyfin attendus. Un fichier Compose modifié après la création du conteneur peut ne pas correspondre à l’environnement d’exécution actuel.
Pour un service natif, examinez l’unité systemd ainsi que tout fichier d’environnement qu’elle charge. Si la définition d’exécution et vos notes divergent, fiez-vous à l’environnement d’exécution, puis décidez s’il faut recréer le service avec le chemin souhaité.
Confirmez le chemin dans les informations de démarrage de Jellyfin
Après avoir noté le chemin attendu, redémarrez une fois le service, puis lisez les premières lignes du démarrage de Jellyfin. Recherchez les chemins configurés des données, du cache ou du stockage et comparez-les avec la définition du processus ou du conteneur que vous venez d’examiner.
Ne considérez pas une connexion Web réussie comme la preuve que le bon répertoire de configuration est actif. Jellyfin peut démarrer normalement avec un chemin de configuration vierge ou ancien et afficher une interface valide, alors que les paramètres utilisateur, le réseau, les plugins ou les tâches planifiées proviennent du mauvais état.
Lors du déplacement d’un serveur multimédia entre différentes méthodes de déploiement, la même rigueur concernant les chemins s’applique à l’ensemble de la pile. Un bon point de départ pratique est la configuration d’un centre multimédia Jellyfin à domicile, où le chemin de l’application, le chemin des médias et le chemin d’accès sont traités comme des éléments distincts de la configuration.
Utilisez une modification de configuration sans risque comme test discriminant
Si deux répertoires candidats semblent toujours plausibles, arrêtez Jellyfin avant de modifier un fichier de configuration XML du serveur. Choisissez un paramètre réversible produisant un effet évident et modifiez-le uniquement dans le répertoire supposé actif. Évitez les données utilisateur, les chemins des bibliothèques ou tout élément susceptible de déclencher une analyse complète simplement pour vérifier quel fichier est utilisé.
Démarrez Jellyfin et vérifiez si le paramètre choisi apparaît. Si c’est le cas, arrêtez de nouveau le service, annulez la modification, puis redémarrez-le pour confirmer sa persistance. Si le paramètre n’apparaît pas, le fichier n’est pas actif ou une source de configuration prioritaire le remplace.
Ce test A/B contrôlé hors ligne est plus fiable que la comparaison des dates de modification, car les outils de sauvegarde, les mises à niveau de paquets et les éditeurs peuvent tous modifier des fichiers inactifs. Jellyfin documente ces options de configuration comme généralement statiques et destinées à être définies avant le démarrage du serveur. Évitez donc les modifications à chaud, sauf si un paramètre particulier documente explicitement un autre comportement.
Arrêtez-vous une fois le chemin actif confirmé après un redémarrage
La conclusion est confirmée lorsque la définition d’exécution, les informations de démarrage et une modification de configuration réversible désignent tous le même répertoire après un redémarrage. Notez ce chemin dans la documentation de votre déploiement et dans le périmètre de sauvegarde.
Si le chemin actif change après la recréation du conteneur, examinez la manière dont le volume et les variables d’environnement sont générés au lieu de modifier sans cesse les fichiers de Jellyfin. Le problème vient alors de l’état du déploiement, et non de l’analyseur de configuration de Jellyfin.
Ne sollicitez de l’aide que si le chemin d’exécution est sans ambiguïté, mais que Jellyfin ignore systématiquement un paramètre valide du fichier actif. Conservez le journal de démarrage et la version exacte avant de demander de l’assistance afin de distinguer le problème d’une simple duplication de fichiers.
Produits recommandés
Assistance et conseils
Plus à lire
Jellyfin doit-il utiliser un compte partagé unique ou des comptes distincts pour chaque membre du foyer ?
Choisissez les comptes familiaux Jellyfin selon les limites d’identité, d’accès, de contrôle parental et de récupération dont vous avez besoin.
Pourquoi l’utilisation de la mémoire de Jellyfin reste-t-elle élevée une fois la tâche terminée ?
Distinguez la croissance du processus Jellyfin du cache Linux, et n’intervenez que lorsque la mémoire continue d’augmenter ou crée une réelle pression.
Signes indiquant qu’une configuration de stockage Jellyfin devient un risque pour la récupération des données
Auditez les rôles de stockage de Jellyfin, séparez l’état actif des sauvegardes et des données reconstructibles, puis validez la disposition par une restauration.
