Métadonnées et mise(s) à jour

Bélisaire · Décembre 28, 2019, 12:08:01

Bonjour tous.
Êtes-vous confronté à ce phénomène : il suffit que regarde des photos, sans les modifier, pour que Lightroom signale ensuite ces fichiers comme ayant des métadonnées non à jour. Quelqu'un saurait-il expliquer ce phénomène ? Est-ce que la lecture de photos (on va dire « anciennes ») avec une version récente de LR entraîne une modification des métadonnées ? Merci.

Samoreen · Décembre 28, 2019, 13:52:35

Citation de: Bélisaire le Décembre 28, 2019, 12:08:01
Êtes-vous confronté à ce phénomène : il suffit que regarde des photos, sans les modifier, pour que Lightroom signale ensuite ces fichiers comme ayant des métadonnées non à jour. Quelqu'un saurait-il expliquer ce phénomène ? Est-ce que la lecture de photos (on va dire « anciennes ») avec une version récente de LR entraîne une modification des métadonnées ? Merci.

Ah oui, je peux expliquer. J'ai étudié ce bug aussi vieux que Lightroom lui-même en long, en large et en travers. J'ai complètement caractérisé le problème en traçant l'erreur dans la base de données, j'ai expliqué comment reproduire le problème, j'ai fait un rapport complet expliquant où était l'erreur,... Bref, j'ai donné toutes les infos permettant de corriger ce bug pénible. Ils n'ont pas bougé.

Tout est là : https://feedback.photoshop.com/photoshop_family/topics/wrong-timestamp-stored-in-lightroom-catalog-causing-wrong-metadata-status-all-windows-versions

Samoreen · Décembre 28, 2019, 14:05:03

Si la lecture du fil cité plus haut est trop longue, voici une explication plus brève...

Quand on affiche une image qui n'a pas été vue depuis longtemps, l'aperçu a probablement été purgé. Quand LR reconstruit l'aperçu, il inscrit la date et l'heure dans le catalogue et dans le XMP. Problème : le plus souvent, ces valeurs diffèrent que quelques fractions de secondes ou de quelques secondes. Comme c'est la comparaison entre ces 2 valeurs qui indique si le XMP est à jour, en retard sur le catalogue ou bien en avance (cas d'une modification extérieure à LR), l'image est aussitôt marquée comme non à jour.

Faire un Ctrl-S suffit parfois à régler le problème mais le plus souvent, le tag "métadonnées non à jour" revient au bout de quelques secondes. La seule parade connue est la suivante :

- Faire Ctrl-S pour enregistrer le XMP. Il est effectivement écrit, j'ai vérifié (mais il n'a pas nécessairement le bon timestamp.
- Relire les données du XMP soit par le menu Métadonnées, soit par un clic-droit sur l'image | Lire les métadonnées depuis le fichier (traduction approximative, je travaille en anglais).
- Le catalogue contiendra alors le même timestamp que le XMP.
- Le problème est réglé temporairement jusqu'à ce que l'aperçu de l'image soit purgé. Et au prochain visionnage, ça recommencera, ou pas.

Bélisaire · Décembre 28, 2019, 16:30:27

Merci pour ces explications. Enfin. Il y a un moment déjà que je me heurtais à ce bug, et je m'étonne que dans le fil de discussion on évoque l'éventualité qu'une poignée seulement d'utilisateurs y soient confrontés. (Ce serait bien d'avoir ici quelques retours).
Ce qui y est décrit correspond exactement à ce que j'ai observé. Plus encore: quand un fichier revient sans arrêt en mode « Métadonnées non à jour » après avoir été pourtant sauvegardé, une lecture « depuis le fichier » ne suffit pas toujours à résoudre le problème: il revient sans arrêt après quelques secondes comme devant être mis à jour. À tel point, parfois, que j'ai cru que le fichier était corrompu. Effacer le xmp correspondant ne suffit pas. Le seul moyen que j'ai trouvé alors était... de supprimer le fichier lui-même (question d'agacement)... après (tout de même) l'avoir converti en jpg (je n'ai pas souvenir que les autres formats --dng, tif -- aient été concluants.
Me voilà informé. Merci encore.

Col Hanzaplast · Décembre 28, 2019, 16:45:44

Citation de: Bélisaire le Décembre 28, 2019, 16:30:27Je m'étonne que dans le fil de discussion on évoque l'éventualité qu'une poignée seulement d'utilisateurs y soient confrontés. (Ce serait bien d'avoir ici quelques retours).

Si je comprends bien ceux qui n'utilisent pas les XMP ne sont pas concernés. Je n'ai jamais utilisé les XMP et je ne dois pas être le seul.

Bélisaire · Décembre 28, 2019, 17:03:44

Samoreen te répondra avec certitude. Moi, je vais (hélas) rester dans le flou : il me semble bien avoir eu ce problème avec des dng et, sauf erreur, le dng n'est pas flanqué d'un xmp.

Samoreen · Décembre 28, 2019, 17:52:42

Citation de: Col Hanzaplast le Décembre 28, 2019, 16:45:44
Si je comprends bien ceux qui n'utilisent pas les XMP ne sont pas concernés. Je n'ai jamais utilisé les XMP et je ne dois pas être le seul.

Le problème est directement lié à la comparaison entre le timestamp du XMP et celui de l'image correspondante dans le catalogue. Cependant, je suppose que le même problème peut survenir, et pour les mêmes raisons, avec les fichiers dans lesquels LR écrit des métadonnées et/ou des corrections. Je ne l'ai jamais vérifié mais en toute logique, on devrait observer les mêmes effets. Beaucoup d'utilisateurs ne s'aperçoivent pas du problème soit parce qu'ils n'affichent pas l'icône "statut des métadonnées" dans leurs vignettes, soit parce qu'ils ne s'intéressent pas du tout à l'état de ces métadonnées (ils n'utilisent jamais le filtre correspondant). Mais je n'ai aucun doute sur le fait que le bug est là pour tout le monde.

L'erreur vient du fait que LR n'écrit pas en même temps sur les 2 destinations. La bonne procédure serait de stocker un timestamp unique en mémoire et d'écrire cette même valeur dans le catalogue et dans le XMP (ou le fichier DNG...) même si cela se fait avec quelques secondes de décalage. Il semble que LR ait une approche plus primaire. Il inscrit la date et l'heure correspondant au moment où il écrit dans le fichier. C'est assez idiot. Si le programme n'est pas trop occupé avec d'autres opérations d'entrée/sortie, l'écart peut être très faible et donc considéré comme négligeable par LR. Mais si beaucoup d'opérations disques sont exécutées en parallèle (par exemple, (re)création des aperçus pour tout un dossier), les écritures peuvent être décalées de manière significative. Et la valeur du décalage sera positive ou négative en fonction de quelle opération aura été exécutée en premier. Résultat : petite flèche en haut ou en bas selon les cas.

Tout ça est bien gênant, en particulier pour ceux qui utilisent les XMP comme sauvegarde de leurs réglages ou pour effectuer des transferts vers d'autres machines. Et ça dure a priori depuis que Lightroom existe.

J'ai une petite idée sur le fait que cela n'ait jamais été corrigé. N'oublions pas qu'une bonne partie de l'interface utilisateur est écrite en langage de scripting LUA (un choix dont je persiste à dire qu'il est catastrophique). C'est un langage assez indigent qui ne permet pratiquement aucun contrôle entre tâches : pas de communication inter-processus, pas de communication inter-threads, pas de gestion des exceptions. Il n'est donc pas impossible que l'idée que j'ai émise plus haut (stocker provisoirement une valeur unique du timestamp) ne puisse pas être mise en place facilement ou bien que cela demande trop d'efforts pour la correction d'un bug qu'ils considèrent comme mineur (ce qu'il n'est pas).

Je ne vous laisse aucun espoir sur une correction éventuelle. J'ai eu il y a 2 ou 3 ans un échange un peu vif avec un représentant Adobe sur leur forum de feedback après qu'il ait annoncé que ce bug ne serait pas corrigé parce que ce n'était pas possible. Il s'est ensuite repris mais cela semble confirmer ce que j'ai expliqué ci-dessus.

Bélisaire · Décembre 28, 2019, 18:43:51

Cette explication technique (et compréhensible) est la bienvenue. Et je suis content... pour moi aussi : je n'y connais rien en technique, mais j'observe juste

.
On fera avec, et je ne penserai plus que mon fichier récalcitrant est corrompu.

ChatOuille · Décembre 28, 2019, 20:02:57

Merci pour tes recherches. Je n'ai pas examiné le problème sous ce point de vue exactement, mais je suis tellement habitué que quand je tape Ctrl+S il me dit que ce n'est pas possible d'enregistrer et je dois répéter l'opération. On connaît la bête et on vit avec.

Bélisaire · Janvier 01, 2020, 17:57:14

Je viens de faire un test avec une photo récalcitrante, en ce sens qu'elle s'inscruste dans « Métadonnées non à jour ».
Enregistrer les métadonnées dans le fichier ou lire les métadonnées depuis le fichier n'aboutit à rien.
Exporter cette même photo (ARW) en DNG ne règle pas le problème (me voilà avec deux images non à jour).
Modifier la photo et sauvegarder à nouveau ne change rien.
Exporter en TIF masque le problème.

Bonne année à tous.

tkosak · Janvier 01, 2020, 20:23:27

Citation de: Bélisaire le Janvier 01, 2020, 17:57:14
Je viens de faire un test avec une photo récalcitrante, en ce sens qu'elle s'inscruste dans « Métadonnées non à jour ».
Enregistrer les métadonnées dans le fichier ou lire les métadonnées depuis le fichier n'aboutit à rien.
Exporter cette même photo (ARW) en DNG ne règle pas le problème (me voilà avec deux images non à jour).
Modifier la photo et sauvegarder à nouveau ne change rien.
Exporter en TIF masque le problème.

Bonne année à tous.

Une suggestion de manip à faire : en dehors de LR, tu vas renommer le .xmp de ton raw "récalcitrant". Logiquement, LR va couiner pour la mise à jour des métadonnées. Tu lui dis de mettre à jour, logiquement il recrée le .xmp. Là, suspens insoutenable, LR cessera-t'il de faire l'imbécile? (et tu n'oublies pas de faire le ménage : supprimer le .xmp en trop...)
Une variante à ce tester : ouvrir le .xmp, supprimer tout son contenu, refermer (en sauvegardant, bien sûr).

Nikojorj · Janvier 01, 2020, 23:52:47

Citation de: Samoreen le Décembre 28, 2019, 17:52:42
Beaucoup d'utilisateurs ne s'aperçoivent pas du problème soit parce qu'ils n'affichent pas l'icône "statut des métadonnées" dans leurs vignettes, soit parce qu'ils ne s'intéressent pas du tout à l'état de ces métadonnées (ils n'utilisent jamais le filtre correspondant). Mais je n'ai aucun doute sur le fait que le bug est là pour tout le monde.

Sans utiliser le badge "métadonnées à jour" affiché ni la collection associée, il y a peut-être un autre symptôme : à la fermeture de LR, un message me prévient souvent que LR n'a pas fini d'écrire des métadonnées, alors que je n'ai pas de telle opération en cours.
Ça collerait avec le bug discuté ici, je pense.

tkosak · Janvier 02, 2020, 08:55:33

Citation de: Nikojorj le Janvier 01, 2020, 23:52:47
Sans utiliser le badge "métadonnées à jour" affiché ni la collection associée, il y a peut-être un autre symptôme : à la fermeture de LR, un message me prévient souvent que LR n'a pas fini d'écrire des métadonnées, alors que je n'ai pas de telle opération en cours.
Ça collerait avec le bug discuté ici, je pense.

J'ai parfois ce message alors que j'ai aussi l'affichage du badge...

Autre manifestation du bug : là je viens de déplacer mes photos sur un autre disque, et pour des images qui n'ont pas changé depuis plusieurs années, je me retrouve avec une foultitude de photos avec un pb de métadonnées. Une fois les mises à jour faites, comme une mauvaise épidémie, ce maudit badge revient, de façon erratique, pas toujours les mêmes images (en fait je n'ai rien repéré...), et toujours à partir de la page écran affichée dans le module bibliothèque (dans la logique de LR, c'est normal).
J'ai même fait un ctrl+S pour la totalité du catalogue (quand même pas loin de 60000 images), le job de copie sur disque a tourné plusieurs heures, je reviens ce matin et j'ai encore (ou à nouveau) quelques conflits... Ptêt'ben que j'va ignorer cette merdouille...

Ah oui, une fois les photos à conflit sélectionnées, il m'a semblé que LR était plus efficace en cliquant sur le pitit bouton du panneau de droite (cf capture d'écran) mais ça n'a aucune logique a priori : sans un doute une vue de mon esprit embrumé.
Pour info, LR 6.10 sur windoouz 10

Samoreen · Janvier 02, 2020, 10:58:20

Pour répondre en partie aux remarques ci-dessus :

- Plus le nombre de photos sur lesquelles on essaie de corriger simultanément le problème en faisant un Ctrl-S est grand, plus les chances de provoquer à nouveau le bug sont élevées. En effet, en multipliant le nombre d'opérations disque menées en parallèle, on augmente la probabilité d'avoir un écart significatif entre le timestamp de l'image dans le catalogue et le timestamp de son XMP. Je pense qu'il vaut mieux procéder par petits lots ou bien corriger plus fréquemment. Personnellement, j'ai créé une collection dynamique qui contient toutes les images ayant le badge "métadonnées non à jour". Je la visite régulièrement. Un Ctrl-A suivi d'un Ctrl-S élimine une bonne partie des images. Pour les cas réfractaires, un Ctrl-A suivi d'un Ctrl-S (par sécurité pour s'assurer que tout est bien écrit dans le XMP) ) puis suivi d'une lecture des métadonnées depuis le fichier corrige le problème. En général, et jusqu'à la prochaine apparition du bug.

- Pour les cas où la manip de lecture depuis le fichier ne suffit pas, je ne sais pas. J'ai déjà eu ce cas quelquefois ainsi que le problème décrit par Nikojorj mais je ne l'ai pas encore caractérisé. Pour ce dernier problème, il se peut que LR "pense" que des opérations soient effectivement en cours sans que cela soit visible via les barres de progression habituelles. On en revient probablement à des soucis liés au langage LUA et à l'absence d'outils de synchronisation dans ce langage. Il doit y avoir des circonstances où un fil d'exécution n'a pas les moyens de vérifier si une opération d'entrée-sortie lancée par un autre fil d'exécution est ou non terminée. Pour faire une comparaison simpliste, c'est un peu comme si le "dirty flag" d'un document Word n'était pas remis à 0 après que l'on ait enregistré le document. Word refusera toujours de se fermer car il pensera que le document n'est pas enregistré.

- Pour le dire de manière plus technique, l'interface utilisateur de LR n'est pas gérée comme une machine à états finis parce que le langage utilisé ne le permet pas. Ce qui veut dire qu'il n'y pas de "centre de contrôle" qui permet d'assurer la cohérence des actions utilisateurs ainsi que celle de l'état des éléments de l'UI (menus, boutons, commandes diverses,...). À mon humble avis, c'est ce qui explique la plupart des bugs de l'UI et la difficulté qu'ils ont à tracer et à caractériser les bugs. Un bon exemple de cet état de fait (et pour moi quasiment une preuve - ce comportement est typique de ce genre d'erreur) est ce bug lui aussi assez ancien : https://feedback.photoshop.com/photoshop_family/topics/folder-favorite-setting-cannot-be-changed . J'ai décrit le moyen de le reproduire mais ils n'arrivent pas à le corriger. Le choix de LUA est une erreur majeure et je crois que les utilisateurs auront à en subir les conséquences ad vitam eternam.

- La probabilité d'apparition du bug est directement liée à la fréquence de purge définie dans les préférences du catalogue. Je pense que ceux qui ont choisi "Jamais" voient le bug beaucoup moins souvent que ceux qui ont choisi une purge quotidienne.

Bélisaire · Janvier 02, 2020, 11:24:28

Pour tkosak #10 : comme indiqué dans mon message #3, renommer ou supprimer le xmp reste sans effet. J'ai essayé le clic sur l'icône, sans succès.

Pour Nikojorj # 11 : J'ai la certitude que ce n'est pas la cause du dysfonctionnement dans la mesure où, ces temps-ci, je laisse LR ouvert toute la journée (à moins qu'il ne s'arrête jamais d'écrire). Par ailleurs, les métadonnées, je ne laisse pas LR les écrire quand il le veut: c'est moi qui décide (enfin, j'espère) à partir d'une collection dynamique créée pour l'occasion. Je suis également maître du temps. Je n'ai encore jamais reçu d'avertissement d'écriture de la part de Lightroom.

Pour Samoreen # 13 : je fais partie de ceux qui ont choisi « jamais » dans les paramètres du catalogue (si on parle bien de la suppression des aperçus). Si oui, je puis donc m'estimer heureux.

Merci à tous pour vos retours.

Bélisaire · Janvier 02, 2020, 11:31:42

J'ajoute (plutôt que de modifier le message précédent), l'info le vaut bien: je viens de procéder à l'astuce proposée par tkosak : ouvrir le xmp, supprimer le contenu, sauvegarder. De retour dans LR, l'image a un nouveau badge (connu): avec « importer les métadonnées depuis le fichier », l'image est à jour et disparaît de ma vue. Belle astuce. Bravo

. - J'espère ne pas déchanter dans quelques minutes...).

A la réflexion, c'est curieux dans la mesure où la suppression du xmp et sa recréation par LR n'ont pas d'effet.

tkosak · Janvier 02, 2020, 13:45:56

Je viens de trouver une méthode PARFAITE pour ne pas avoir de problèmes de mise à jour des métadonnées : il suffit de ne pas traiter ses images. Simple, non?
OK, je retourne me coucher...

Bélisaire · Janvier 03, 2020, 12:23:56

Juste pour dire (et je pense que ce sera bon), j'ai une fois de plus appliqué (avec succès) la « méthode à tkosak » sur une (autre) image dont les métadonnées refusaient de se mettre à jour. L'intitulé exact est Importer les paramètres depuis le disque.

Bélisaire · Janvier 03, 2020, 13:20:05

En fait, non. La « méthode à tkosak », elle est pas bonne

. En procédant ainsi, il y a réinitialisation des paramètres et toutes les modifications effectuées sur l'image dans LR disparaissent. On retrouve donc la photo RAW issue de l'appareil. Et quand on retourne dans l'historique pour revenir à l'état précédent (modifications prises en compte), c'est toujours la galère pour mettre à jour les métadonnées.

Samoreen · Janvier 03, 2020, 16:36:28

Citation de: Bélisaire le Janvier 03, 2020, 13:20:05
En fait, non. La « méthode à tkosak », elle est pas bonne . En procédant ainsi, il y a réinitialisation des paramètres et toutes les modifications effectuées sur l'image dans LR disparaissent. On retrouve donc la photo RAW issue de l'appareil.

Oui, pas de surprise. À mon avis, il y a 2 causes possibles au refus d'enregistrement des métadonnées :

1. Il y a un problème d'écriture ou de permission à cet endroit du disque mais c'est assez peu probable.

2. Le fichier XMP est corrompu et LR n'arrive pas à reconstituer l'arborescence des balises. Si c'est ça, je peux le confirmer, voire le corriger. Il suffit de m'envoyer le XMP en question.

tkosak · Janvier 03, 2020, 17:23:59

Citation de: Bélisaire le Janvier 03, 2020, 13:20:05
En fait, non. La « méthode à tkosak », elle est pas bonne . En procédant ainsi, il y a réinitialisation des paramètres et toutes les modifications effectuées sur l'image dans LR disparaissent. On retrouve donc la photo RAW issue de l'appareil. Et quand on retourne dans l'historique pour revenir à l'état précédent (modifications prises en compte), c'est toujours la galère pour mettre à jour les métadonnées.

Euh... en copiant les métadonnées à partir d'un fichier vide, c'est normal que tu annules tout dans LR... J'espère que les dégâts se limitent à un ou deux fichiers de test!... Sinon, peut-être aurais-tu intérêt à repartir de la dernière sauvegarde du catalogue, si elle n'est pas trop ancienne...

Bélisaire · Janvier 03, 2020, 21:32:05

Citation de: Samoreen le Janvier 03, 2020, 16:36:28
Oui, pas de surprise. À mon avis, il y a 2 causes possibles au refus d'enregistrement des métadonnées :

1. Il y a un problème d'écriture ou de permission à cet endroit du disque mais c'est assez peu probable.

2. Le fichier XMP est corrompu et LR n'arrive pas à reconstituer l'arborescence des balises. Si c'est ça, je peux le confirmer, voire le corriger. Il suffit de m'envoyer le XMP en question.

À mon sens, ni l'un ni l'autre.
Pour le (1), difficile à vérifier, mais effectivement, c'est peu probable, en ce sens que c'est un phénomène qui dure depuis des années, pour de nombreux fichiers. Alors, toujours au même endroit ?... D'autant qu'entre-temps, j'ai changé de PC, de disque dur, etc.
Pour le (2), je dis « impossible » dans la mesure où je supprime physiquement le XMP dans l'explorateur de Windows. LR le crée à nouveau ensuite. Cela ferait beaucoup trop de fichiers corrompus.

Citation de: tkosak le Janvier 03, 2020, 17:23:59
Euh... en copiant les métadonnées à partir d'un fichier vide, c'est normal que tu annules tout dans LR... J'espère que les dégâts se limitent à un ou deux fichiers de test!... Sinon, peut-être aurais-tu intérêt à repartir de la dernière sauvegarde du catalogue, si elle n'est pas trop ancienne...

Il n'y a pas de dégâts. Le XMP n'est pas nécessaire à LR. Il a une copie de ce qui est écrit dans ses données du catalogue. Je suis allé dans l'historique, j'ai annulé la dernière commande, à savoir la réinitialisation, et mon image est revenue comme je l'avais modifiée avant effacement du XMP. (Pour l'anecdote : avant de savoir ce qu'était un XMP, il m'est arrivé de les supprimer TOUS (des milliers); LR n'a eu aucun mal à reconstituer mes images).

Ajout : J'ai dupliqué le fichier dans un autre endroit (disque dur différent, avec et sans xmp): le problème demeure. Je me demande si LR ne réagit pas à une sorte de modification.

Bélisaire · Janvier 04, 2020, 11:21:11

Nouveau test. De ma photo récalcitrante à la mise à jour des métadonnées, j'ai suivi l'historique; je suis revenu en arrière en ôtant des modifications tout en mettant à jour à chaque étape. Après la cinquante-septième étape (après « ajouter un contour » et à « Ombres »), le fichier accepte de se mettre à jour. Tout cela m'avance à quoi ? A rien. Sauf à me conforter dans l'idée que la difficulté de se mettre à jour est en relation avec certaines modifications apportées à l'image, mais pas avec l'historique proprement dit : j'ai fait une copie de cette photo et du XMP, j'ai renommé les deux fichiers et j'ai importé l'image dans Lightroom. L'historique disparaît mais l'impossibilité de mettre à jour subsiste.

(Mais non, je ne suis pas obsédé).

Nikojorj · Janvier 04, 2020, 12:01:29

Bélisaire, as-tu lu les explications de Samoreen? Il explique de manière très convaincante le bug...

Citation de: Samoreen le Décembre 28, 2019, 17:52:42
Le problème est directement lié à la comparaison entre le timestamp du XMP et celui de l'image correspondante dans le catalogue.
[...]
L'erreur vient du fait que LR n'écrit pas en même temps sur les 2 destinations. La bonne procédure serait de stocker un timestamp unique en mémoire et d'écrire cette même valeur dans le catalogue et dans le XMP (ou le fichier DNG...) même si cela se fait avec quelques secondes de décalage. Il semble que LR ait une approche plus primaire. Il inscrit la date et l'heure correspondant au moment où il écrit dans le fichier. C'est assez idiot. Si le programme n'est pas trop occupé avec d'autres opérations d'entrée/sortie, l'écart peut être très faible et donc considéré comme négligeable par LR. Mais si beaucoup d'opérations disques sont exécutées en parallèle (par exemple, (re)création des aperçus pour tout un dossier), les écritures peuvent être décalées de manière significative. Et la valeur du décalage sera positive ou négative en fonction de quelle opération aura été exécutée en premier. Résultat : petite flèche en haut ou en bas selon les cas.

Bélisaire · Janvier 04, 2020, 13:15:13

Citation de: Nikojorj le Janvier 04, 2020, 12:01:29
Bélisaire, as-tu lu les explications de Samoreen? Il explique de manière très convaincante le bug...

J'ai lu, j'ai compris. L'explication... n'explique cependant pas qu'un fichier (ou plusieurs) ne puisse(nt) jamais être mis à jour. Comment comprendre, par exemple, qu'en cliquant sur une étape de l'historique, le fichier se met à jour sans problème; qu'en cliquant sur l'étape précédente, la mise à jour ne se fait pas. Cette manipulation (après/avant*) est reproductible à souhait avec toujours la même conséquence (maj/pas de maj). Le décalage d'écriture, dont parle Samoreen, ne tient pas ici.

après/avant = par ordre d'apparition dans l'historique; après = modif plus ancienne.