Immich affiche des données obsolètes après la modification du chemin de stockage
Les données Immich obsolètes après une modification du chemin de stockage peuvent avoir trois causes distinctes qu’il ne faut pas confondre : le déplacement de la racine des médias gérés, la modification du chemin d’importation d’une bibliothèque externe ou l’utilisation d’un client qui affiche encore un état mis en cache. Les versions modernes d’Immich peuvent réconcilier un emplacement de médias gérés déplacé lorsque l’emplacement configuré et le montage du volume restent cohérents, tandis que les déplacements de bibliothèques externes peuvent toujours être traités comme de nouvelles identités d’éléments.
Conservez l’ancien chemin et la base de données avant toute nouvelle analyse. Vérifiez d’abord quel chemin le conteneur en cours d’exécution voit réellement, puis déterminez si l’enregistrement côté serveur d’Immich est incorrect ou si un seul client est obsolète. Cette distinction permet de déterminer s’il faut réparer un montage, restaurer un chemin stable visible par le conteneur, analyser un sous-ensemble de test ou vider uniquement le cache du client.
Distinguer le déplacement de la racine des médias gérés de celui d’une bibliothèque externe
Si vous avez modifié l’emplacement hôte des téléversements gérés par Immich, vérifiez que le paramètre d’emplacement effectif des médias et le montage hôte-conteneur ont été modifiés ensemble. Un déplacement moderne de médias gérés ne doit pas être diagnostiqué de la même manière que le renommage du chemin d’importation d’une bibliothèque externe.
La cartographie de l’état persistant d’Immich de ZimaSpace est utile ici, car la base de données et les chemins du système de fichiers constituent une même limite de récupération. Les bons fichiers sur l’hôte ne suffisent pas si le conteneur est monté ailleurs.
Si la racine des médias gérés ne correspond pas, corrigez d’abord l’environnement et le mappage des volumes, puis redémarrez le service avant d’exécuter les tâches de bibliothèque. Si le chemin modifié appartient à une bibliothèque externe, conservez la base de données intacte et testez cette branche séparément.
Conserver si possible le chemin du conteneur de la bibliothèque externe
Pour une bibliothèque externe, le déplacement du stockage côté hôte est plus sûr lorsque le chemin d’importation visible par le conteneur peut rester inchangé. Si le chemin présenté à Immich change, notez un petit ensemble d’identifiants d’éléments, d’albums, de personnes et d’anciens chemins avant une analyse, afin de déterminer si les éléments existants ont été réassociés ou recréés.
Un rapport sur la modification du chemin d’une bibliothèque externe dans Immich décrit des fichiers déplacés traités comme de nouveaux éléments, avec un retraitement et la perte de relations propres à Immich. Il s’agit d’un cas dépendant de la version, mais il confirme la règle prudente selon laquelle la modification du chemin d’une bibliothèque externe n’est pas automatiquement un renommage transparent.
Si un sous-ensemble de test apparaît comme de nouveaux éléments tandis que les anciens enregistrements deviennent manquants ou sont placés dans la corbeille, interrompez l’analyse complète. Restaurez l’ancien chemin visible par le conteneur si possible ou utilisez une méthode de migration adaptée à la version ; ne réécrivez pas manuellement les chemins dans la base de données de production sans sauvegarde testée.
Ne confondez pas cette branche avec une migration du modèle de stockage pour les fichiers gérés par Immich. Le symptôme peut sembler similaire dans la chronologie, mais la propriété des fichiers et la méthode de migration prise en charge sont différentes.
Distinguer les chemins enregistrés sur le serveur du cache du client
Examinez le même élément connu depuis le client web et un autre client authentifié, puis comparez le résultat aux journaux du serveur ou au chemin visible par le serveur. Si les tâches côté serveur utilisent encore l’ancien chemin, vider le cache du navigateur ne pourra pas corriger l’enregistrement sous-jacent.
Un problème ultérieur de métadonnées liées à un ancien chemin dans Immich montre que le traitement continuait à faire référence à un ancien chemin de bibliothèque externe après un renommage. Cela justifie fortement de vérifier les chemins utilisés par les tâches avant d’accuser l’interface mobile ou web.
Si le chemin côté serveur est correct, mais qu’une seule vue web est obsolète, actualisez-la ou videz le cache de ce client, puis testez à nouveau le fichier d’origine. Les miniatures mises en cache et l’état obsolète du client peuvent donner l’impression qu’un serveur corrigé est défaillant, tandis qu’un aperçu mis en cache peut aussi faire paraître sain un chemin serveur défectueux.
Réparer la limite de chemin la plus restreinte et valider une nouvelle analyse contrôlée
Effectuez une seule correction réversible : synchronisez le paramètre des médias gérés et le montage, restaurez l’ancien chemin de la bibliothèque externe visible par le conteneur, corrigez un chemin d’importation ou videz le cache d’un client. Effectuez une sauvegarde de la base de données avant toute action susceptible d’entraîner la redécouverte d’une grande bibliothèque.
Lancez la plus petite nouvelle analyse pratique et vérifiez que les enregistrements existants restent associés, que les erreurs liées aux anciens chemins cessent et qu’aucun doublon d’anciens et de nouveaux éléments n’apparaît. Ouvrez ensuite quelques originaux, vérifiez les relations avec les albums et les personnes, effectuez une recherche et redémarrez la pile.
Demandez une intervention supplémentaire si les enregistrements des anciens et des nouveaux chemins restent actifs simultanément, si une grande bibliothèque externe est retraitée de manière inattendue ou si des relations disparaissent alors que les originaux restent lisibles. Conservez la cartographie exacte des montages avant et après, la version d’Immich, les identifiants des éléments concernés, le comportement de la casse du système de fichiers et l’horodatage de la sauvegarde de la base de données.
Produits recommandés
Assistance et conseils
Plus à lire
Comment optimiser les connexions à la base de données d’Immich pour des conteneurs simultanés
N’augmentez pas d’abord max_connections. Mesurez les sessions Immich, totalisez la demande de chaque conteneur, préservez une marge pour l’administration et n’optimisez que le goulot...
Comment empêcher les tâches ou importations en double dans Immich
Séparez les tâches répétées des ressources en double. Utilisez un chemin d’ingestion canonique, contrôlez les nouvelles tentatives et les changements de chemin, puis testez...
Comment réparer Immich après le remplissage de son volume de base de données
Ne supprimez jamais les journaux WAL de PostgreSQL pour libérer de l’espace. Arrêtez les écritures d’Immich, préservez l’état de la base de données, ajoutez...
