Pourquoi les photos Immich nouvellement importées mettent-elles du temps à devenir accessibles dans la recherche ?

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.

Les nouvelles photos deviennent généralement consultables après la fin du traitement en arrière-plan, mais des tâches bloquées et des filtres de recherche peuvent produire des symptômes similaires de résultats manquants.

Un téléphone a terminé l’envoi d’un album de vacances vers le serveur familial, mais une recherche sur la plage ne renvoie que des photos plus anciennes. Les résultats manquants peuvent être en attente d’analyse, échouer à une étape antérieure du traitement ou être exclus par la requête actuelle. Il est plus important de distinguer ces situations que de juger l’importation entière à partir d’une recherche n’ayant rien renvoyé.

Une photo importée peut encore être en attente d’indexation

Un envoi accepté, une vignette visible dans la chronologie et une fiche de recherche sémantique terminée sont trois étapes différentes. Le traitement en arrière-plan permet au serveur d’accepter les requêtes sans terminer simultanément toutes les étapes d’analyse. Cette séparation offre davantage de flexibilité, mais signifie aussi que le seul compteur d’envois ne peut pas indiquer à une famille quand chaque nouvelle image correspondra à une requête en langage naturel.

Des files d’attente distinctes rendent cette distinction observable. Un développeur ayant créé un visualiseur de file d’attente pour Immich affiche les tâches en attente, actives et terminées, ainsi que des graphiques de vitesse de traitement. L’idée utile n’est pas l’outil supplémentaire en lui-même : c’est que plusieurs activités de traitement progressent indépendamment, et qu’une période de transfert calme ne signifie donc pas nécessairement que la bibliothèque est terminée.

Pour une file d’attente donnée à titre d’exemple, 12 000 tâches éligibles en attente, traitées à un rythme constant de 100 par minute, nécessitent environ 120 minutes après l’arrêt des arrivées. Si 80 nouvelles tâches arrivent chaque minute, la diminution nette n’est que de 20. Les tâches réelles diffèrent en coût ; ce calcul explique donc le comportement d’un retard plutôt qu’il ne prédit le délai de fin d’Immich.

Trois situations différentes peuvent sembler constituer le même retard

Il faut distinguer trois situations : une file d’attente volontairement en pause, une file d’attente qui progresse lentement et des tâches qui échouent à répétition avant de produire le résultat requis. Dans le premier cas, l’exécution n’est pas autorisée ; dans le deuxième, le débit est insuffisant par rapport au rythme d’arrivée ; dans le troisième, une erreur précise fait perdre du temps. Un nombre élevé de tâches en attente peut correspondre aux trois situations.

Un délai d’expiration des métadonnées signalé illustre la troisième situation, sans prouver une limite matérielle générale. L’auteur du signalement a observé des échecs au bout de 120 secondes pour des vidéos stockées dans une bibliothèque reposant sur NFS, alors que l’extraction des mêmes fichiers depuis l’hôte était rapide. Ce contraste localise une divergence dans le chemin de traitement ; il ne montre pas que tout stockage NAS ou toute importation volumineuse se comporte ainsi.

Si le nombre de tâches en attente diminue et que les échecs restent stables, une couverture retardée est compatible avec une file d’attente qui se résorbe. S’il ne diminue pas, il faut d’abord distinguer les tâches en pause des erreurs actives avant de conclure que le système est surchargé. Il s’agit d’une limite de classification, pas d’une recommandation visant à vider les files d’attente, redémarrer tous les services ou relancer toute la collection familiale.

Le périmètre de recherche peut imiter un indexage inachevé

Une fois l’état du traitement établi, conservez le compte, le périmètre de l’album, le filtre de date et la requête. Une recherche effectuée depuis un autre compte du foyer peut modifier les résultats admissibles, même sur le même serveur. Une requête sémantique classe également les résultats par similarité au lieu de garantir un inventaire exact ; l’absence d’une correspondance visuelle ne prouve donc pas à elle seule que l’indexation est inachevée.

Les aperçus HEIC manquants ajoutent une autre ambiguïté : l’original peut être présent alors que son dérivé d’affichage est indisponible. Le format, le comportement du décodeur ou un profil d’image particulier peuvent influer sur ce chemin. Une vignette manquante et un vecteur de recherche manquant sont deux observations différentes, même si la même photo expose ces deux problèmes à l’utilisateur.

L’explication par une file d’attente normale cesse de s’appliquer lorsque le même petit sous-ensemble échoue systématiquement après la fin du traitement du reste du groupe. À l’inverse, une recherche réussie sur un élément connu, accompagnée d’une faible correspondance sémantique, oriente vers la pertinence de la requête ou le comportement du modèle. Ne réimportez pas les originaux simplement parce que la première formulation d’une recherche n’a pas permis de les retrouver.

-15% OFF

Utilisez un petit groupe pour distinguer l’attente du blocage

Choisissez un petit ensemble de ressources récemment importées, avec des dates identifiables et des contenus variés, ainsi qu’un ensemble plus ancien dont le fonctionnement est déjà établi. Notez le moment où chaque original est accepté, celui où son aperçu s’ouvre, celui où les tâches pertinentes se terminent et si une requête fixe permet de le retrouver. Répétez les observations à intervalles consignés sans modifier les modèles ni lancer une tâche de retraitement de toute la bibliothèque.

La planification des importations peut différer volontairement le traitement en arrière-plan. Une version d’immich-go a introduit la mise en pause des tâches pendant les envois afin d’éviter les conflits simultanés de mise à jour des métadonnées. Il s’agit d’un indice concernant une politique précise d’importation en masse, et non de la preuve que l’application mobile native met les tâches en pause de la même manière ; notez quel importateur et quelle version ont effectivement produit le groupe.

Interprétez une hausse du nombre de tâches terminées, avec des résultats stables pour les éléments plus anciens, comme un rattrapage ; des échecs répétés sur les mêmes fichiers comme un problème de traitement ; et des résultats différents selon les comptes comme une question de périmètre. Si la progression s’arrête, transmettez ces observations ainsi que les détails de version. Un diagnostic utile permet de circonscrire l’étape défaillante sans supprimer les éléments permettant l’analyse ni modifier plusieurs variables simultanément.

Centre Tech & IA

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.