Échec du décodeur ou échec du processus de génération des miniatures ? Test des aperçus RAW manquants

Testez un fichier RAW avec le même décodeur en dehors de la file d'attente, puis comparez l'affectation du travail et les journaux des tâches afin de distinguer la prise en charge du format d'un échec d'exécution.

Cette décision est importante lorsque les fichiers RAW originaux s'importent correctement, mais que les aperçus restent vides ou en attente. Les deux états en concurrence sont le décodage RAW non pris en charge ou en échec, et un problème de file d'attente des miniatures, de processus worker, d'autorisations ou de stockage de sortie. Commencez avec une configuration enregistrée et des données jetables, examinez une seule branche à la fois et arrêtez-vous si le test accroît le risque de perte de données, de problème d'autorisations ou d'indisponibilité.

Distinguer un décodage RAW non pris en charge ou en échec d'un problème de file d'attente des miniatures, de processus worker, d'autorisations ou de stockage de sortie

Consignez l'environnement avant toute modification : versions des logiciels et du firmware, identités des appareils, chemin de montage ou réseau, espace libre, autorisations et symptôme observable. La référence initiale doit conserver suffisamment de détails pour reproduire le cas où les fichiers RAW originaux s'importent correctement, mais où les aperçus restent vides ou en attente.

La première hypothèse est un décodage RAW non pris en charge ou en échec. La seconde est un problème de file d'attente des miniatures, de processus worker, d'autorisations ou de stockage de sortie. Les types de médias pris en charge par Immich actuels définissent le mécanisme ou la limite de commande utilisés lors du test ; ils ne remplacent pas les observations faites sur ce serveur domestique précis.

Rédigez la condition d'acceptation et la condition d'arrêt avant d'exécuter le test discriminant. Une réussite doit modifier les éléments probants prédits par une branche tout en laissant les services indépendants inchangés ; un échec doit ramener le système à l'état enregistré au lieu de déclencher une série de corrections spéculatives.

Exécuter un seul test discriminant contrôlé

Utilisez ce test discriminant : exécutez des sondes de métadonnées et de décodage sur un fichier RAW copié, placez une tâche de miniature dans la file d'attente et suivez-la de la file jusqu'au fichier de sortie. Gardez la charge, le client, le chemin, l'ensemble de fichiers et le calendrier constants afin que le résultat soit attribuable à la variable modifiée.

Utilisez la prise en charge des décodeurs libvips pour sélectionner le champ permettant réellement de distinguer les branches, puis capturez son horodatage, son code de sortie, le texte de l'erreur, l'identité de l'appareil ou de l'instantané, la latence, les octets transférés, les autorisations et l'état de récupération. Une sortie de commande réussie ne suffit pas lorsque l'identité, la durabilité ou l'état de l'application constitue l'élément vérifié.

Répétez le test une fois après un redémarrage, une reconnexion, un remontage ou un cache froid lorsque cet événement fait partie de la condition d'origine. Si la première exécution est destructive ou si l'environnement ne peut pas être restauré, arrêtez-vous et reproduisez le test sur une copie jetable.

exiftool sample.CR3
# Décodez une copie avec la pile d'images installée, puis placez une tâche de miniature dans la file d'attente

Interpréter la branche étayée par les éléments probants

RÉUSSITE : le décodeur échoue avant le traitement par la file d'attente, ou le décodage réussit tandis que le processus worker n'écrit jamais le dérivé. Consignez la version, l'identité et la charge exactes ayant réussi afin que la conclusion reste conditionnelle plutôt que de devenir une affirmation universelle.

ÉCHEC : un seul appareil photo ou mode de compression échoue ; la prise en charge doit donc être limitée à cet échantillon. Un échec ne prouve pas automatiquement la branche opposée lorsque le réseau, la mémoire, les autorisations ou la cohérence de la source peuvent influencer les deux ; isolez ces dépendances communes avant toute escalade.

RÉSULTAT EXCEPTIONNEL OU AMBIGU : conservez les originaux, arrêtez les tempêtes de nouvelles tentatives et maintenez un chemin d'aperçu JPEG connu comme fonctionnel pendant l'enquête. Conservez les journaux et n'exécutez aucune commande de réparation, de purge, de destruction, de repartitionnement ou de modification récursive des propriétaires avant qu'une copie récupérable n'existe.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Appliquer l'action correspondante et reproduire l'échec d'origine

Appliquez l'action correspondant à la branche observée, puis reproduisez la condition d'origine plutôt qu'un substitut simplifié. La décision n'est valable que lorsque le décodeur échoue avant le traitement par la file d'attente, ou que le décodage réussit tandis que le processus worker n'écrit jamais le dérivé, sur deux cycles ou lors du redémarrage, de la mise en veille, de l'interruption ou de la transition de charge concernés.

Utilisez les bibliothèques Immich en lecture seule pour vérifier le flux de travail dépendant le plus proche, mais conservez le déclencheur d'origine inchangé. Les jeux de données, partages, conteneurs, utilisateurs et points de récupération indépendants doivent conserver leur accès et leur calendrier précédents.

La limite d'arrêt est explicite : si un seul appareil photo ou mode de compression échoue, la prise en charge doit être limitée à cet échantillon ; revenez à la dernière configuration vérifiée, conservez les éléments probants et ne passez à un test plus approfondi de la plateforme ou du matériel que lorsque la branche est reproductible.

Une fois le résultat cible confirmé, comparez-le à la planification des tâches de miniatures afin que la correction ne déplace pas le risque vers un service voisin. Un test cible réussi accompagné d'un nouvel échec de sauvegarde, d'identité, de délai d'attente ou de disponibilité reste une modification échouée.

FAQ

Pour diagnostiquer l'absence d'aperçu RAW, les recherches restantes portent généralement sur les raisons pour lesquelles certains fichiers RAW d'un même appareil photo fonctionnent, sur la possibilité que les autorisations de fichiers semblent correctes alors que les processus workers échouent encore, et sur l'opportunité de régénérer les aperçus à l'échelle de la bibliothèque. Les réponses ci-dessous maintiennent ces cas limites séparés de la décision principale.

La limite d'acceptation ne change pas : le décodeur échoue avant le traitement par la file d'attente, ou le décodage réussit tandis que le processus worker n'écrit jamais le dérivé. Si une condition ultérieure modifie le système de fichiers, l'identité, le chemin réseau ou la version de l'application, répétez uniquement le test discriminant concerné par cette modification.

Arrêtez d'élargir l'expérience lorsqu'un seul appareil photo ou mode de compression échoue ; la prise en charge doit alors être limitée à cet échantillon. À ce stade, conservez les originaux, arrêtez les tempêtes de nouvelles tentatives et maintenez un chemin d'aperçu JPEG connu comme fonctionnel pendant l'enquête ; conservez les éléments probants avant d'escalader vers le responsable de la plateforme, du stockage ou du matériel.

Pourquoi certains fichiers RAW d'un même appareil photo fonctionnent-ils ?

Le firmware de l'appareil photo, le mode de compression, l'aperçu intégré et la version du décodeur peuvent différer malgré une même extension.

Les autorisations de fichiers peuvent-elles sembler correctes alors que les processus workers échouent encore ?

Oui. Le processus worker peut utiliser un chemin de conteneur, un UID ou un point de montage de sortie différent.

Faut-il régénérer les aperçus à l'échelle de la bibliothèque ?

Pas avant qu'un échantillon ait réussi et que la capacité disponible de la file d'attente et du stockage puisse absorber la charge.

Le diagnostic est terminé lorsque la même charge fait correspondre les éléments probants au décodage RAW non pris en charge ou en échec, ou au problème de file d'attente des miniatures, de processus worker, d'autorisations ou de stockage de sortie, et que l'action correspondante supprime le symptôme d'origine sans en créer un second. Si aucune branche ne reste reproductible, conservez les journaux et l'état enregistré intacts ; l'incertitude justifie une escalade, pas l'empilement de nouvelles corrections.