Lightroom: Metadata save fails sporadically

  • 2
  • Problem
  • Updated 8 months ago
  • (Edited)
Intermittent failures when saving metadata to file:

1. Metadata is frequently marked by LR as having been changed by another application when it has not.  This problem has always occurred intermittently and I do not know what is causing it.  (This occurs for files stored on my Mac's local SSD as well as files on the NAS.)

2. Many images failed to save because LR had read-only access.  This is not correct.  Saving the same batch of files again succeeded for more of them; and more the next time; and so on until all had saved properly.

3. Two images (a panorama and an HDR, both created in LR) failed because it was an "unknown file format".  Saving this a couple more times made it work.

Something is definitely unwell here but I can't figure out what.  Other than saving, everything is working fine.

LR 2015.7 on macOS 10.12,  saving files over a fast wired network to a Synology NAS mounted in the Finder with SMB.
Photo of anonymess


  • 26 Posts
  • 4 Reply Likes

Posted 1 year ago

  • 2
Photo of Paul Plak

Paul Plak

  • 138 Posts
  • 18 Reply Likes
I often see #1,  issuing the warning message metadata has been changed, do you want to save, while I am not aware any change  has been made to the metadata by any program whatsoever
Photo of John R. Ellis

John R. Ellis, Champion

  • 3163 Posts
  • 758 Reply Likes
Over the years and major versions of LR, many people have reported that LR intermittently reports incorrect metadata status, but there's never been any resolution.  I see it very infrequently with LR CC on my SSD, but in past versions of LR I saw it much more often.

If you're sure that you're not using any external application or utility to modify the contents of your photo files (other than backup), I generally recommend that people just ignore the incorrect status -- it doesn't hurt just to select all the photos and do Metadata > Save To Metadata.

Your other symptoms -- intermittent reports of read-only access and unknown file format -- smells like an issue with the NAS.  You could search for "synology" in the LR user-to-user forum and read through the numerous threads for clues  -- others have reported intermittent symptoms as well.  (But that doesn't necessarily mean it's an issue with Synology, just that Synology is a popular NAS.)
Photo of Patrick Philippot

Patrick Philippot

  • 230 Posts
  • 30 Reply Likes

I have already given a technical analysis of this bug there :

So, once you know what is happening, the problem (which is lasting since version 1 of LR) is easy to fix. Therefore, this is not a technical problem. Just, nobody cares about this issue at Adobe.

I can even say more about this bug...

Examining 3 images having a wrong metadata status (marked unsaved although I used Ctrl-S against them)... Hands away from LR, closing it. Then I looked at the following data :

1. Last modification date of the XMP file as seen by Windows.

2. Last metadata modification date inserted in the XMP file.

3. touchTime field in the Adobe_Images table of the catalog database. The format is special : it's the Cocoa format (online converter here : For example the value 459813336.759782 in the touchTime field means 2015/07/28 - 21:55:36 GMT.

I opened the catalog database with SQLite Expert Personal.

For the relevant image #1 and #2 are identical. The touchTime value was completely different (up to 10 minutes difference).

I returned to LR and did a Ctrl-S for these images, exited LR and looked again at the time stamps mentioned above. Once again, #1 et #2 were identical and the touchTime value in the catalog was this time shifted by 10 seconds. The shift can be positive or negative (which may of course result in getting a down or an up arrow on the vignette).

So there's obviously a bug in the code routine writing the touchTime field. I also observed that multiple images belonging to different folders and collections and added to the catalog at different dates, had exactly the same value in the touch_time field. This just doesn't make any sense, especially because some of these images have not been edited since years and others have been edited recently.

I made another very interesting test. I purged all 1:1 previews, started a rebuild and looked at a smart collection in the Library module showing the images having a metadata status not in sync. This collection was initially empty. Hands off from the keyboard, just looking at the screen. And images started to appear in the collection while LR was rebuilding the previews.

For those interested in making tests on their system, here is how to access the touchTime timestamp in the catalog database :

1. Exit LR, open the catalog in an SQLite manager like SQLite Expert Personal.
2. Open the AgLibraryFile table.
3. Look for the target image by filename or by using an SQL request or by sorting by filename on the idx_filename column.
4. Once the image has been found, note the value in the id_local field.
5. Open the Adobe_images table and look for the line where the rootfile field contains the value found in step #4.
6. Copy the value of the touchTime field : should be something like 403622498.760918 for example.
7. Convert it using the online converter at . You can then compare this value to the value described in #1 et #2 above. Since this value is a GMT value, you have to compensate for the Time Zone indicated in the XMP file.

Now the developers know what is wrong and if they had done this analysis work just in time, this bug would have been eliminated since years.