Lightroom Classic: Wrong timestamp stored in catalog causing wrong metadata status (all Windows versions)

  • 9
  • Problem
  • Updated 5 hours ago
  • (Edited)
Hi,

The problem I describe below is not new (I observed this at least since version 3) but this time I took the time to investigate more deeply...

From time to time, LR tells me that the XMP file of a given image is no longer in sync with the metadata in the catalog. Most often, this is correct because I made changes without recording the XMP file (Ctrl-S - I'm not using the automatic XMP updating mode). But very often, this information is simply wrong. I didn't change anything to the image and suddenly, the little down arrow appears in the upper right corner of the thumbnail.

Hitting Ctrl-S may or may not fix the problem. Sometimes, the little down arrow reappears after a few seconds or minutes although I didn't do anything (hands away from keyboard and mouse).

I recently did the following test for multiple images unduly displaying the "metadata status changed" flag. I compared the following values :

1. Windows "last modified" timestamp for the XMP file.
2. Value of the xmp:MetadataDate field in the XMP file.
3. touchTime column value for that image in the Adobe_images table of the catalog (which is a SQLite database).

The touchTime value is stored in a special format, so I had a hard time converting it to a readable date/time value. However, I will not explain this and how I navigated the database in order to access this timestamp (this requires some knowledge about databases).

Result:
For all the images tested, values #1 and #2 were always strictly identical. The touchTime value was always off (sometimes about 10-15seconds, sometimes much more). So no wonder that LR thought that the XMP file and the metadata in the catalog were not in sync.

Moreover, the difference in time can be negative of positive. So LR displays the up or down arrow accordingly (meaning that the XMP file is older or newer than the metadata in the catalog, respectively - which is wrong in both cases).

I explained above that sometimes, the image reappears as "not in sync" just a few seconds or minutes after I did a Ctrl-S. In that case, a quick look at the database showed me that the touchTime field had not been updated. So the time difference causing the image to be flagged as "not in sync" was still there. In that case, the problem can be fixed by reading the metadata from the XMP file which was actually correctly updated. This operation updates the catalog and everything is in sync again.

Anyway, there's something very wrong in the computation of the touchTime value of the Adobe_images table. That seems to be obvious. This wrong timestamp generates in turn a wrong metadata status.

I made another interesting test :

1. I started from a situation were 0 image was flagged as "not in sync" with the XMP file.

2. I purged all 1:1 previews and started a Build all 1:1 previews.

3. In Library mode, I setup a filter to show only the images that had the Metadata Status set to "has been changed". I got a cup of coffee and waited.

At the beginning of the generation process, no image was displayed in the grid, as expected. While LR was building the previews, images unduly tagged as "not in sync" started to appear. I got about 200 of them. For all these images, the metadata status was just plain wrong. These were finalized images not modified since a long time and for which the XMP file had been timely updated after the last modification. I checked the touchTime field for some of them and each time it was different from the Windows "last modified" timestamp and from the xmp:MetadataDate field of the XMP file as mentioned above.

So now I know what's going wrong but I'd like to have this problem fixed after all these years.

Thanks in advance.
Photo of Patrick Philippot

Patrick Philippot

  • 529 Posts
  • 160 Reply Likes
  • frustrated

Posted 4 years ago

  • 9
Photo of Rikk Flohr

Rikk Flohr, Official Rep

  • 6139 Posts
  • 1357 Reply Likes
I've asked the team to review this thread again. .
Photo of Patrick Philippot

Patrick Philippot

  • 529 Posts
  • 160 Reply Likes
Thanks.

Given the information provided in this thread by John R. Ellis and me, the problem should be easy to fix. At least, it should be easy to be more tolerant when comparing the timestamps. A very small difference shouldn't be taken into account.
Photo of Patrick Voss de Haan

Patrick Voss de Haan

  • 2 Posts
  • 6 Reply Likes
Thank you for responding.
I think it would be appreciated if you or the team could keep us posted. 
Photo of Smit K

Smit K, Employee

  • 251 Posts
  • 125 Reply Likes
Hi Patrick,

We have been trying to reproduce the issue and have been successful with soem DNG files.

Could you confirm if you are facing this issue with only DNG files or all types of files.?

Thanks,
Smit
Lightroom Classic CC Team
Photo of Michael Becker

Michael Becker

  • 11 Posts
  • 11 Reply Likes
Dear Adobe team.

1. This software bug is there since YEARS !

2. It is EASY to reproduce: PLEASE read Patrick Philippot's comment.

3. Please hire some expert from backup software companies - they know how to determine, whether a file has changed or not.

In other words: Please act and correct this!

Not so kind regards
Michael
Photo of Michael Becker

Michael Becker

  • 11 Posts
  • 11 Reply Likes
Dear Lightroom-Team,
anything new?
Photo of Patrick Philippot

Patrick Philippot

  • 529 Posts
  • 159 Reply Likes
The more I think about this bug and others that are lasting since years, the more I'm convinced that the incapacity to fix them is related to the programming language used to develop a big part of LR : LUA. Beside many other flaws, this language lacks the necessary features to effectively track, spot and fix bugs. After all these years, I'm still wondering why this disastrous choice has been made.

Anyway, there should be a way to fix this bug.

Wake up !
Photo of Michael Becker

Michael Becker

  • 11 Posts
  • 11 Reply Likes
Dear Adobe Team.
I would appreciate any - ANY ! - kind of feedback to this problem.

Thank you and kind remarks,
Michael
Photo of Michael Becker

Michael Becker

  • 11 Posts
  • 11 Reply Likes
Hi Adobe.

Another try to help you:
May it be that you store a "Cache Flag" in the metadata?
So - whenever an image goes in or off the cache, you change the metadata, i.e. this flag..
If so - this is ill-designed.==> You have to correct this and store such a flag elsewhere, e.g. in the catalogue!

Kind regards.Michael 
(Edited)
Photo of Patrick Philippot

Patrick Philippot

  • 529 Posts
  • 160 Reply Likes
Hi,

Not only this bug still has not been fixed in version 9 after all these years but things now appear to be worse than usual. After installation, I found myself with hundreds of files with their metadata status allegedly marked as "not saved" which is plain wrong. When using the usual trick that temporarily fixes the problem (Ctrl-S, then Read Metatadata from file), I had to "read the metadata from file" multiple times for some of these images before the metadata status got the correct value. And as usual, the status returned to "not saved" for some files after a few seconds.

I regret that the developers of LR have not enough self-esteem and pride to definitively fix this infamous bug lasting since the early versions of LR and disturbing the workflow of many users. I personally would be ashamed of this.