Pourquoi Immich ne renvoie-t-il plus les photos privées interrogeables après un redémarrage ?

Immich cesse généralement de renvoyer les photos privées consultables après un redémarrage parce que Smart Search a perdu son chemin d’accès au machine learning, n’a pas terminé le chargement initial de son modèle ou ne parvient pas à terminer les tâches et les lectures du stockage nécessaires à la création des représentations vectorielles de recherche.

Si la chronologie affiche toujours les originaux, les photos ne sont probablement pas manquantes : c’est la couche de recherche qui est incomplète. Considérez d’abord un résultat vide comme un problème de chemin de service, préservez la base de données et la bibliothèque d’importation, puis distinguez un conteneur de machine learning indisponible, des tâches en retard, un point de terminaison incorrect ou un échec de permissions sur un chemin persistant avant de reconstruire quoi que ce soit.

Différencier l’absence de résultats de recherche de l’absence de photos

Ouvrez directement plusieurs éléments connus depuis la chronologie, les albums et une bibliothèque privée avant de tester la recherche. Si cela fonctionne, la base de données peut localiser les enregistrements et Immich peut lire les fichiers ; en cas d’échec, il s’agit d’un incident plus général touchant la bibliothèque ou le stockage. Arrêtez alors les modifications propres à la recherche et protégez les chemins concernés.

Effectuez trois recherches reproductibles : un terme qui fonctionnait auparavant, un terme visuellement évident et un élément importé récemment, après la fin prévue de son traitement en arrière-plan. Notez si les résultats sont vides, obsolètes ou limités aux anciennes photos. Ces résultats permettent de distinguer une défaillance totale du point de terminaison d’un retard d’indexation.

Un fil de dépannage communautaire rassemble les vérifications Smart Search liées aux redémarrages, notamment l’accessibilité du point de terminaison et la relance des tâches. Utilisez sa séquence de diagnostic de la couche de recherche comme élément de comparaison, et non comme raison de supprimer la base de données ou de régénérer chaque élément.

Vérifier le chemin du machine learning après un redémarrage

Examinez l’état de santé du serveur et du conteneur de machine learning, puis testez l’URL de machine learning configurée depuis l’espace de noms réseau qui l’appelle. Un point de terminaison accessible avec des requêtes de modèle réussies valide cette branche ; un refus de connexion, un échec de résolution de nom ou un conteneur défaillant identifie le chemin de service à réparer.

Comparez le nom du service déployé, le port, la valeur d’environnement, la version de l’image et l’appartenance au réseau avec la dernière définition Compose fonctionnelle. Recréez uniquement le conteneur concerné après avoir corrigé l’écart. Un simple redémarrage ne remplace pas un environnement obsolète du conteneur : confirmez donc la valeur effective dans la charge recréée.

Un cas signalé avec Immich v2.6.1 associait l’échec de Smart Search à un conteneur de machine learning défaillant. Le rapport d’incident concernant cette version justifie la vérification de l’état de santé et des journaux ; il ne prouve pas que chaque échec après redémarrage soit dû à cette régression.

Vérifier la disponibilité du modèle, les tâches et les chemins persistants

Surveillez les journaux du machine learning tout en envoyant une recherche connue. La première requête peut charger ou télécharger un modèle et consommer temporairement davantage de mémoire ; une progression suivie d’une réponse réussie valide cette étape. Des expulsions répétées, une terminaison pour manque de mémoire ou un échec de téléchargement indiquent un problème de mémoire, de persistance du cache ou de réseau.

Examinez le nombre de tâches Smart Search et les échecs récents sans les effacer. Si le point de terminaison est sain mais que des tâches restent en échec ou en attente, relancez un petit lot contrôlé et observez si les compteurs diminuent. Si un élément est traité avec succès, corrigez la concurrence des travailleurs ou la dépendance défaillante avant de planifier une réindexation complète.

Vérifiez que la base de données, la bibliothèque d’importation et le cache du modèle utilisent les chemins persistants prévus avec l’identité attendue. Le guide ZimaSpace associé sur le fonctionnement de la reconnaissance dans Immich aide à distinguer les problèmes d’accès et de portée d’indexation de l’absence d’un original.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Appliquer le correctif approprié et tester deux redémarrages

Corrigez uniquement la cause confirmée : restaurez le nom du point de terminaison, recréez le conteneur avec le bon environnement, rendez le cache du modèle persistant, réduisez la concurrence mesurée, corrigez le propriétaire ou relancez les tâches Smart Search en échec. Gardez l’ancien fichier Compose et une sauvegarde de la base de données à portée de main ; ne supprimez pas les représentations vectorielles en première intention.

Retestez les trois mêmes requêtes, un ancien élément et un nouvel import. La validation exige des résultats utiles, des files de tâches qui diminuent, des originaux lisibles et un état de santé stable du machine learning. Redémarrez la pile dans l’ordre normal de ses dépendances et recommencez, puis redémarrez une fois l’hôte pour vérifier que les montages et la résolution de noms résistent au démarrage.

Revenez en arrière si les résultats diminuent, si les originaux deviennent illisibles ou si la base de données signale des erreurs de cohérence. Si le même échec réapparaît après deux redémarrages, transmettez la version d’Immich, le point de terminaison effectif, l’état de santé du conteneur, les journaux pertinents, le nombre de tâches, le nom du modèle et les mappages de montage ; gardez l’instance précédente, encore consultable, isolée mais récupérable.