Évitez les tâches et importations Jellyfin en double en attribuant à chaque opération un planificateur, un processus d’écriture, un chemin surveillé et un signal d’achèvement.
Des analyses, importations ou tâches de métadonnées sont-elles dupliquées après un redémarrage, la recréation d’un conteneur ou l’ajout d’une nouvelle automatisation ? Notez le nom de la tâche, l’heure de début, l’ID du conteneur, le planificateur, le répertoire surveillé et la sortie avant de désactiver quoi que ce soit. La solution sûre consiste à supprimer les responsabilités qui se chevauchent plutôt qu’à masquer une entrée en double.
Trouvez chaque planificateur susceptible de lancer le même travail
Vérifiez les tâches planifiées de Jellyfin, les hooks de redémarrage des conteneurs, les tâches cron ou les minuteurs systemd de l’hôte, le post-traitement du gestionnaire de téléchargements et tout service auxiliaire qui appelle l’API. Comparez les horodatages et les identifiants de processus de deux exécutions. Si les deux tâches démarrent lors du même événement, désactivez le déclencheur secondaire et laissez la tâche principale inchangée.
Les tâches Jellyfin peuvent s’exécuter périodiquement ou manuellement, et les tâches de démarrage peuvent s’exécuter avant qu’un partage réseau soit disponible (référence sur le calendrier des tâches). Considérez la disponibilité du point de montage comme une condition préalable au lieu d’autoriser une seconde importation pour compenser.
Vérifiez si le doublon apparaît après un démarrage, un webhook ou une nouvelle tentative manuelle. Le déclencheur permet de déterminer quel responsable doit être désactivé : désactiver toutes les tâches planifiées masque la cause sans empêcher sa réapparition.
Attribuez à chaque chemin un seul processus d’écriture et une identité stable
Assurez-vous qu’un seul téléchargeur ou importateur déplace les fichiers vers la bibliothèque et que chaque conteneur utilise le même chemin canonique. Deux conteneurs avec des mappages différents peuvent importer le même fichier sous deux identités distinctes. Comparez l’inode, la somme de contrôle, le chemin et les droits de propriété d’une paire de doublons avant toute suppression.
Si le fichier source est renommé ou reformaté, Jellyfin peut le considérer comme un nouvel élément plutôt que comme une mise à jour. Effectuez un déplacement contrôlé, lancez une seule analyse et vérifiez le nombre d’éléments attendu avant de réactiver l’automatisation.
Comparez les étiquettes des conteneurs actifs et les chemins surveillés, et pas seulement le fichier de configuration présent sur le disque. Un ancien conteneur peut conserver un observateur obsolète actif après un nouveau déploiement.
Validez la prévention après un redémarrage et une nouvelle tentative
Après avoir modifié un déclencheur, redémarrez la pile et attendez une seule occurrence de la fenêtre planifiée. Confirmez la présence d’un seul processus, d’un seul événement d’importation, d’une seule modification de la base de données et d’un seul fichier final. Répétez ensuite une exécution échouée ou interrompue pour vérifier que la nouvelle tentative ne lance pas une seconde copie.
Faites remonter le problème si les doublons persistent avec un seul planificateur et un seul chemin, si la base de données contient des identités contradictoires ou si un plugin recrée les tâches de façon répétée. Conservez les fichiers multimédias d’origine et la sauvegarde de la base de données jusqu’à la réussite du nettoyage et du test de prévention.
Après avoir supprimé le processus d’écriture secondaire, effectuez une importation normale, puis une nouvelle tentative interrompue. Le résultat attendu est un seul événement dans la base de données et un seul fichier final pour chaque élément source.
Confirmez la règle de prévention après le redémarrage
Redémarrez la pile et attendez la fin d’une fenêtre planifiée avec uniquement le planificateur choisi activé. Notez le processus, le chemin et l’événement de la base de données afin de rendre la limite de responsabilité observable.
Conservez la configuration lorsqu’une nouvelle tentative ne lance pas de seconde importation et que la bibliothèque contient un seul élément valide. Réactivez une automatisation à la fois si un autre service est nécessaire.
Faites remonter le problème si les doublons réapparaissent avec un seul processus d’écriture, si la base de données contient des identités contradictoires ou si un plugin recrée les tâches désactivées.
Assistance et conseils
Plus à lire

Comment optimiser les connexions à la base de données de Jellyfin pour des conteneurs simultanés
Commencez avec un seul propriétaire de base de données et mesurez le comportement des verrous SQLite ; n’ajoutez un autre backend que lorsque la...

Comment réparer Jellyfin après le remplissage de son volume de base de données
Arrêtez les écritures, préservez la base de données et les fichiers WAL, libérez de l’espace sans supprimer aveuglément l’état, puis vérifiez l’intégrité et la...

Pourquoi Jellyfin recrée-t-il les fichiers manquants avec le mauvais propriétaire ?
Une propriété incorrecte provient généralement d’une incohérence d’identité ou d’un chemin d’importation différent ; vérifiez l’utilisateur actif du conteneur avant de modifier les autorisations.

