Comment éviter la réécriture des métadonnées multimédias lors de la maintenance de la bibliothèque

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 réécritures des métadonnées multimédias sont plus faciles à éviter lorsque les champs personnalisés et les illustrations reposent sur des sources durables avant le début de la maintenance à l’échelle de la bibliothèque.

Une analyse, une actualisation des fournisseurs, un nettoyage de la base de données, un déplacement de chemin ou une mise à niveau du serveur peuvent toucher des couches très différentes d’une bibliothèque multimédia. Avant la maintenance, identifiez les titres, affiches, collections, fichiers NFO et champs modifiés manuellement qui font autorité ; verrouillez les éléments que le serveur permet de verrouiller, sauvegardez les fichiers associés locaux et les illustrations, puis exécutez le mode d’actualisation le moins destructeur sur un élément de test. Ne choisissez pas « remplacer toutes les métadonnées » simplement parce que la tâche de maintenance concerne toute la bibliothèque.

Inventoriez les métadonnées personnalisées avant la maintenance

Choisissez un ensemble représentatif de films et d’épisodes, puis notez les titres personnalisés, les noms de tri, les identifiants des fournisseurs, les collections, les affiches, les arrière-plans, les éditions et les descriptions corrigées manuellement. Indiquez si chaque valeur existe uniquement dans la base de données ou également dans un fichier NFO ou d’illustration local.

Un guide récent sur les métadonnées Jellyfin recommande de verrouiller les champs que vous avez personnalisés avant toute opération étendue sur les métadonnées.

Si vous ne pouvez pas déterminer quelles valeurs sont intentionnelles, ne lancez pas d’actualisation remplaçant tout. Exportez d’abord un petit échantillon d’audit ou faites-en des captures d’écran afin de détecter une réécriture indésirable au lieu de vous en apercevoir plusieurs semaines plus tard.

Sauvegardez les fichiers NFO et les illustrations locales comme sources durables

Lorsque la bibliothèque utilise des fichiers NFO, des affiches ou des arrière-plans locaux comme métadonnées de référence, copiez-les avec les fichiers multimédias ou incluez-les dans la sauvegarde de maintenance. Vérifiez les horodatages et les sommes de contrôle de quelques échantillons.

Jellyfin prend en charge les fichiers NFO comme métadonnées locales et peut enregistrer les métadonnées dans ces fichiers lorsque l’enregistreur NFO est activé.

Ne supposez pas qu’une simple sauvegarde de la base de données conserve tous les fichiers associés gérés manuellement. À l’inverse, ne considérez pas le fichier NFO comme la source de référence si la bibliothèque n’a jamais stocké les modifications que dans la base de données du serveur.

Privilégiez les illustrations locales lorsque la stabilité des affiches est importante

Pour les affiches ou les arrière-plans qui doivent résister aux changements de fournisseur, stockez l’image choisie en utilisant la convention de nommage local prise en charge par le serveur multimédia et sauvegardez-la avec la bibliothèque multimédia.

Plexopedia montre que les affiches locales résistent aux changements de fournisseur en conservant les illustrations comme ressources locales durables.

Testez un titre avant d’appliquer la convention à toute la bibliothèque. Les illustrations locales améliorent la reproductibilité, mais elles créent aussi des fichiers que les politiques de sauvegarde, de synchronisation et d’autorisations doivent préserver.

Utilisez le mode d’actualisation le moins destructeur

Faites la distinction entre une analyse normale de la bibliothèque, une actualisation des métadonnées, une opération de remplacement de toutes les métadonnées et une option de remplacement des images existantes. Une maintenance qui ne modifie que les chemins de stockage ou les index de la base de données nécessite rarement de remplacer tous les champs et toutes les images.

Un cas de dépannage Emby illustre comment le remplacement de tout peut écraser les illustrations lors d’une actualisation manuelle.

Commencez par « rechercher les fichiers nouveaux ou mis à jour », ou par l’équivalent ciblé de votre plateforme, lorsque cela répond à l’objectif. Ne passez à une actualisation destructive que pour les éléments dont les métadonnées doivent réellement être reconstruites.

Vérifiez la source de référence avant d’écrire dans les dossiers multimédias

Si plusieurs applications partagent la même arborescence multimédia, déterminez laquelle est autorisée à écrire les fichiers NFO, les illustrations ou les balises. Deux serveurs écrivant dans les mêmes fichiers associés peuvent transformer une maintenance courante en conflit de métadonnées entre applications.

Les recommandations de Firecore sur les métadonnées montrent que les illustrations peuvent être remplacées volontairement au niveau du client et de la bibliothèque.

Dans la mesure du possible, conservez un seul processus d’écriture durable pour les fichiers associés partagés, ou montez le stockage multimédia en lecture seule pour les applications qui ont uniquement besoin de lire les fichiers. L’objectif est d’avoir une source de référence claire, et non le plus grand nombre possible de processus écrivant les métadonnées.

Exécutez d’abord la maintenance sur une petite bibliothèque de test

Créez une bibliothèque temporaire ou sélectionnez un petit dossier contenant des illustrations personnalisées, des fichiers NFO locaux, des collections, un titre modifié et un élément ordinaire intact. Exécutez d’abord l’action de maintenance prévue exactement dans cet environnement.

Plex documente que les ressources locales suivent des règles de nommage, afin qu’une bibliothèque de test puisse vérifier que les ressources locales durables sont toujours lues après la maintenance.

Comparez les éléments de test avant et après l’analyse, l’actualisation, la modification de chemin ou la mise à niveau. La politique de maintenance est sûre uniquement lorsque les champs personnalisés restent stables et que les mises à jour prévues des fournisseurs continuent de fonctionner. L’article ZimaSpace associé sur les affiches personnalisées qui réapparaissent après une actualisation constitue la procédure de récupération si les illustrations personnalisées ont déjà été modifiées.

Foire aux questions

Une analyse normale de la bibliothèque réécrit-elle toujours les métadonnées ?

Non. Les modes d’analyse et d’actualisation diffèrent, et le comportement dépend du serveur, des sources de métadonnées et des options sélectionnées. Testez l’action de maintenance exacte au lieu de considérer chaque analyse comme un remplacement de tout.

Les dossiers multimédias doivent-ils être en lecture seule pendant la maintenance ?

Les montages en lecture seule peuvent protéger les fichiers sources et les fichiers associés lorsque le serveur n’a pas besoin d’y écrire, mais ils peuvent aussi empêcher l’enregistrement volontaire de fichiers NFO ou d’illustrations. Définissez cette limite en fonction de votre politique de source de référence.

Une sauvegarde de la base de données des métadonnées suffit-elle à protéger les affiches personnalisées ?

Oui, uniquement si l’affiche est effectivement stockée dans cette base de données ou récupérable depuis la sauvegarde des données de l’application. Les fichiers d’illustrations locales doivent également être sauvegardés en tant que fichiers.

Assistance et conseils

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.