Jellyfin affiche des données obsolètes après la modification d’un chemin de stockage

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Jellyfin Shows Stale Data After a Storage Path Change - Zima Store Online

Jellyfin affiche généralement des données obsolètes après un déplacement du stockage, car le service voit l’ancien chemin, ne peut pas lire le nouveau point de montage ou n’a pas terminé une analyse valide du nouvel emplacement.

Le tableau de bord affiche-t-il d’anciens éléments, des éléments manquants ou un mélange des deux ? Ne supprimez pas d’abord la bibliothèque et ne videz pas sa corbeille. Notez les anciens et nouveaux chemins exacts, l’état du montage, les droits du service et le résultat de l’analyse afin de pouvoir tester chaque branche sans détruire les métadonnées.

Vérifier le chemin réellement visible par Jellyfin

Inspectez le chemin depuis le processus ou le conteneur Jellyfin, et pas uniquement depuis le terminal de l’hôte. Vérifiez que le montage existe après le démarrage, que le compte du service peut répertorier et lire un fichier d’exemple, et que le mappage du conteneur correspond au chemin enregistré dans la configuration de la bibliothèque.

Si le chemin est vide ou inaccessible, corrigez d’abord le montage, l’UID/GID ou le volume du conteneur. Un montage de stockage qui apparaît après une connexion manuelle peut laisser Jellyfin analyser un répertoire vide au démarrage.

Comparez l’ancien et le nouveau chemin dans la configuration de la bibliothèque et dans un enregistrement de la base de données. Si les deux existent encore, Jellyfin peut légitimement afficher un élément valide et une référence obsolète.

Faire la différence entre des métadonnées obsolètes et une analyse échouée

Une fois le chemin accessible, lancez une analyse contrôlée et surveillez les journaux pour vérifier le nom de la bibliothèque, le nombre d’éléments, les erreurs de permission et les fichiers ignorés. Comparez un ancien élément connu avec un fichier nouvellement ajouté. Si l’analyse se termine mais que les anciens chemins persistent, la base de données contient encore l’ancien emplacement ou le nouveau chemin a été ajouté sans supprimer l’ancienne référence.

Ne considérez pas une affiche mise en cache comme la preuve que le fichier multimédia est disponible. Les règles relatives aux chemins de stockage font du système de fichiers monté et du chemin d’application deux vérifications distinctes.

Effectuez une seule analyse contrôlée après avoir corrigé le mappage, puis comparez le nombre d’éléments et un fichier connu. Des analyses répétées avant la correction du chemin peuvent créer un état encore plus déroutant.

Réparer uniquement après avoir confirmé le problème

Corrigez le mappage du chemin ou les permissions, redémarrez une fois, puis relancez l’analyse. Si le chemin enregistré dans la base de données est incorrect, modifiez l’emplacement de la bibliothèque en apportant le changement le plus limité possible et vérifiez le nombre d’éléments attendu avant de supprimer les anciennes entrées. Conservez les données de l’application et une sauvegarde avant toute opération groupée sur les métadonnées.

La récupération est confirmée lorsque le service voit toujours le nouveau chemin après un redémarrage, qu’un client représentatif lit un élément et qu’une seconde analyse ne recrée pas l’état obsolète. Faites remonter le problème lorsque le système de fichiers signale une corruption, que la base de données contient des chemins contradictoires ou que le problème réapparaît après un montage et un redémarrage propres.

Après la réparation, redémarrez avec le montage disponible au démarrage et répétez l’analyse. Les données obsolètes ne sont pas résolues tant que le même chemin ne reste pas visible après le redémarrage.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

Faire remonter le problème lorsque le chemin réapparaît

Conservez le mappage réparé lorsqu’un redémarrage propre, une analyse et la lecture d’un élément représentatif utilisent tous le nouveau chemin sans recréer l’ancienne entrée.

Arrêtez le nettoyage lorsque l’ancien chemin revient, que la base de données contient des identités contradictoires ou que le montage de stockage change entre les analyses. Préservez d’abord la base de données et le mappage actuel des chemins.

Faites remonter le problème vers une restauration depuis une sauvegarde ou une réparation spécifique de la base de données lorsque le système de fichiers est sain, mais que les références obsolètes persistent malgré un mappage et un redémarrage propres.