Comment empêcher les tâches ou importations en double dans Immich
Évitez les tâches ou importations Immich en double en distinguant d’abord deux symptômes différents : le même traitement en arrière-plan qui semble s’exécuter de nouveau, et la même photo qui devient plusieurs ressources. Identifiez ensuite le client, l’importateur, l’analyse de bibliothèque, la modification de chemin ou la nouvelle tentative à l’origine du second événement avant de supprimer quoi que ce soit.
La conception la plus sûre attribue à chaque groupe de ressources un chemin d’ingestion canonique. Une archive cloud historique, une bibliothèque externe et une sauvegarde active du téléphone peuvent toutes être valides, mais le chevauchement de propriété des mêmes fichiers peut créer des enregistrements en double ou des boucles de réimportation qu’aucun nettoyage post-importation ne corrigera de manière fiable.
Déterminez s’il s’agit de traitements répétés ou de ressources en double
Pour les tâches répétées, notez le nom de la file d’attente, l’ID de la ressource, l’heure de début, l’état de réussite ou d’échec et l’événement qui a précédé la nouvelle tâche. Une tâche en aval légitimement créée après le traitement des métadonnées n’est pas la même chose que la nouvelle tentative infinie de la même tâche échouée. Ne videz pas toutes les files d’attente avant de savoir quel schéma est présent.
Pour les ressources en double, comparez la bibliothèque source, le chemin d’origine, le comportement des sommes de contrôle lorsqu’elles sont disponibles, l’état de la sauvegarde de l’appareil, la date de prise de vue et la taille du fichier. La même image visible peut exister sous la forme de deux fichiers différents après une exportation cloud, des modifications de métadonnées, un transcodage ou un traitement de bibliothèque externe fondé sur les chemins, tandis que des fichiers identiques au niveau binaire peuvent aussi exister dans différentes sources de bibliothèque Immich.
Si les importations ordinaires commencent à produire des erreurs répétées de somme de contrôle ou de contrainte d’unicité, préservez la base de données et examinez l’état du schéma et des migrations avant de considérer le problème comme lié à la source d’importation. Des ressources en double provenant de deux types de sources légitimes et un échec de contrainte de base de données sont deux cas différents et ne doivent pas faire l’objet du même nettoyage.
Le guide ZimaSpace consacré à l’état de la sauvegarde du téléphone et à la planification mobile est utile, car un client mobile possède sa propre vision des éléments qui doivent encore être sauvegardés. Un nettoyage côté serveur qui ignore l’état du client peut amener la prochaine session du téléphone à envoyer de nouveau les fichiers.
Utilisez un seul chemin d’ingestion canonique pour chaque groupe de photos existant
Choisissez la manière dont les anciennes photos entreront dans Immich avant d’activer la sauvegarde continue du téléphone : par exemple, importez une seule fois l’archive historique, vérifiez-la, puis laissez le téléphone ne fournir que les nouvelles prises de vue. Si les mêmes fichiers historiques sont à la fois montés comme bibliothèque externe et téléversés dans la bibliothèque de téléversement normale, ne supposez pas qu’une déduplication globale réconciliera les deux sources.
Un rapport de doublons entre sources d’Immich documente la coexistence de contenus identiques provenant d’une bibliothèque externe et de la bibliothèque de téléversement. Considérez cela comme une limite liée au comportement du projet : la propriété de la source est importante. La prévention est donc plus fiable que l’espoir qu’un utilitaire de déduplication ultérieur déduise la copie que vous préférez conserver.
Évitez de déplacer à l’insu d’Immich des fichiers qu’il a téléversés en interne vers une bibliothèque externe lorsque le téléphone les considère encore comme faisant partie de son ensemble de sauvegarde. Si l’architecture de stockage doit changer, effectuez la migration en suivant une procédure documentée, avec des sauvegardes et un petit groupe de test, puis vérifiez que l’application mobile et le serveur sont d’accord avant de supprimer l’ancienne copie.
Contrôlez les nouvelles tentatives et l’état du client avant d’augmenter l’échelle de l’importation
Utilisez un manifeste de préparation pour une importation manuelle volumineuse : notez le chemin source, le nombre de fichiers, le nombre total d’octets et une somme de contrôle stable ou le résultat de l’importateur lorsque cela est possible. Si une importation est interrompue, reprenez-la avec le même outil et la même destination au lieu de lancer un second importateur indépendant sur la même source alors que l’état de la première tâche est incertain.
Un rapport récent de téléversements répétés d’Immich a montré qu’un client mobile retentait continuellement d’envoyer des ressources déjà présentes sur le serveur, avec des erreurs de contrainte d’unicité côté serveur. Considérez cela comme un élément de preuve limité à certaines versions : l’état de sauvegarde du client peut être à l’origine de la boucle. N’en faites pas une généralité sur le comportement des applications mobiles. Les changements de chemin constituent un risque distinct. Maintenez stables les chemins des bibliothèques externes visibles par les conteneurs pendant une importation volumineuse et, si un déplacement du stockage est nécessaire, migrez d’abord un petit groupe. Si la seconde copie n’apparaît qu’après une modification de chemin, suivez la piste de l’identité du chemin plutôt que de réinitialiser l’état de sauvegarde du téléphone.
Testez l’interruption, la nouvelle tentative et une ressource réellement nouvelle
Créez un petit groupe représentatif comprenant des photos ordinaires, des vidéos, une image modifiée et au moins un fichier qui existe déjà dans le chemin de destination. Importez-le une fois, notez le nombre de ressources et leurs ID, puis interrompez une seconde tentative contrôlée ou relancez une analyse selon le flux de travail que vous prévoyez d’utiliser en production.
Le test est concluant s’il n’y a pas de seconde ressource inexpliquée pour le même objet source attendu, si les nouvelles tentatives se stabilisent sans croissance permanente de la file d’attente et si une photo réellement nouvelle est toujours importée correctement. Rouvrez également le client mobile après le test afin que son état de sauvegarde ne diverge pas silencieusement de celui du serveur.
Si les doublons ne réapparaissent qu’entre les sources de téléversement et de bibliothèque externe, repensez la limite de propriété au lieu de les fusionner sans cesse. Si le même ID de ressource reçoit une tâche en échec sans fin, isolez cette tâche et ce fichier. Fournissez, pour l’escalade, le type de source, les chemins, les hachages lorsqu’ils sont pertinents, les versions, l’état de sauvegarde du client et le plus petit groupe reproductible.
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 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...
Pourquoi Immich recrée-t-il les fichiers manquants avec le mauvais propriétaire ?
Immich ne doit pas recréer silencieusement les originaux sources manquants. Identifiez le type de fichier régénéré et le logiciel qui l’a généré, puis corrigez...
