P: Lightroom Classic repeatedly detects metadata conflicts and writes XMP changes when no edits were made

Hi,

many people are experiencing the same issue (metadata disaligned without any reason), I have a catalog with more than 200K pics and this strange bugs is evident to me for many years.

For instance, today I moved a folder (directly in LrC) from the disk of my Mac toward an external USB. After some hours.. some DNG files were not aligned from Metadata point of view. 

A weird behaviour:

• by taking only one picture, with CMD+S the metadata status turns into “Modified to” disc (starting from “Modified”); a second CMD+S turns the metadata status in “Updated”
• by taking more than one picture and pressing CMD+S, the final metadata status directly changes from “Modified” to “Updated”

Last consideration: the same behaviour has been observed with DNG, PSD and TIF files (I should try to import Nikon raw files avoiding to apply the conversion, to see if this long-standing behavior happens with NEF+XMP files too...)

I am experiencing what appears to be the same Lightroom Classic metadata synchronization problem described in this thread. My symptoms are remarkably similar, including thousands of metadata conflicts, thousands of images not up to date, zero images identified as having been changed, and repeated metadata-writing activity despite no intentional changes.

Description of Issue

Lightroom Classic repeatedly displays "Writing Metadata Changes into XMP. Please wait until the process is complete" whenever I optimize my catalog and Lightroom prepares to restart.

This happens even after I have manually selected Metadata > Save Metadata to Files before optimizing the catalog. The process typically takes five minutes or longer.

I have also discovered a very large number of photographs with metadata conflicts, despite having made no intentional external metadata changes to those photographs.

Lightroom Classic Version: 15.6

Operating System: [Insert Windows version/build]

Catalog Size: Approximately 109,000 photographs and videos.

Catalog Location: Local internal C: drive.

Original Image Storage: External conventional hard disk drive.

Automatic XMP Writing: Enabled under Catalog Settings > Metadata.

File Formats: Mixed catalog, including JPEG, TIFF, PSD, AVI video, and predominantly Canon CR2 and CR3 RAW files.

Camera: Canon R1 (current camera).

Other Metadata Applications: I do not use Adobe Bridge or Camera Raw independently. Only a handful of photographs have been opened/edited in Photoshop. The overwhelming majority have only been handled in Lightroom Classic.

Face Recognition / GPS: I do not use People View, face recognition, GPS, or the Map module.

Metadata Status Smart Collection Results

After restarting Lightroom Classic, the counts were:

• Changed on Disk: 68

• Conflict Detected: 21,030

• Has Been Changed: 0

• Not Up to Date: 22,480

These counts are from a catalog containing approximately 109,000 photographs.

Steps Taken to Investigate

1. Created Smart Collections for all four metadata status conditions.

2. Manually selected Metadata > Save Metadata to Files. This did not eliminate the recurring metadata-writing operation.

3. Selected an individual photograph flagged as Conflict Detected and attempted Save Metadata to File. Its XMP modification timestamp did not change, and the conflict remained.

4. Selected Overwrite Settings from the metadata conflict dialog. The XMP modification timestamp updated, but the photograph remained in the Conflict Detected collection.

5. Accidentally selected Read Metadata from File on that same photograph. It disappeared from the Conflict Detected collection, and its edits, masks, and crops remained intact.

6. The photograph subsequently displayed an exclamation point with the message: "There was an unknown error while writing metadata to this photo."

7. Selected Retry Metadata Export. The exclamation point disappeared. However, the associated .ACR file, previously present, disappeared as well. Lightroom's Metadata panel now reports Sidecar Files: XMP only. The photograph's edits and masks remain intact.

Additional Investigation

I inspected the XMP sidecar of an affected Canon CR3 photograph. Its SidecarForExtension field was:

photoshop="CR3"

I did not find the lowercase/uppercase discrepancy described in this thread's original investigation.

Expected Result

After Lightroom successfully writes metadata to the external sidecar files, the photographs should report an up-to-date metadata status, and subsequent catalog optimization/restarts should not repeatedly initiate substantial metadata-writing operations when no new edits have been made.

Actual Result

Thousands of photographs remain flagged as Conflict Detected and Not Up to Date. Lightroom repeatedly initiates metadata-writing operations, even after manually saving metadata and optimizing the catalog. Individual photographs have also displayed unknown metadata-writing errors.

The behavior appears to have started sometime around August 2026, although I cannot establish the precise date.

I have backed up my Lightroom catalog and have deliberately avoided performing any bulk metadata overwrites or mass repairs because I do not want to risk losing legitimate editing or metadata information.

I would appreciate investigation by the Lightroom Classic engineering team. In particular, I would like to know why Lightroom repeatedly identifies these photographs as having metadata conflicts and why successful metadata-writing operations do not consistently resolve the underlying status.

I can provide the Lightroom System Info report and representative XMP/ACR files for examination.

Additional System Information – Lightroom Classic 15.6

I am attaching my complete Lightroom Classic System Info report.

Key system details:

• Windows 11, build 26100

• 64 GB RAM

• 12 logical processors, 3.1 GHz

• NVIDIA RTX A5000 Laptop GPU

• NVIDIA driver 596.52

• Internal Camera Raw version 18.7

• SQLite version 3.45.1

• Catalog path: D:\Lightroom Classic\Lightroom Master Catalog-v13-3.lrcat

The catalog is stored locally. Original photographs are stored on an external conventional HDD.

The problem affects a mixed-format catalog, although the vast majority of photographs are Canon CR2 and CR3 RAW files.

I have backed up the catalog and am preserving representative metadata sidecars for possible examination by Adobe engineering.

I have reviewed several files which the smart collection filter identified as  ‘Metadata Status > is > conflict detected’.  I resolved the conflict by allowing LrC to overwrite the xmp.  When I diff the before vs after content of the xmp, I see some oddities.

All show before values of 

photoshop:SidecarForExtension="arw"

and after values of 

photoshop:SidecarForExtension="ARW"

Is LrC case sensitive and detecting the lower and upper case “ARW” values as a conflict?  The lowercase “arw” was written by LrC 18.1.  No third party or external edits occurred.

Hi ​@jbinco,

Thank you for the detailed write-up. I understand the frustration, especially when the behavior occurs even without making any edits during a session. I want to help narrow down what's happening in your specific case.
 

Some context on what you may be seeing. In Lightroom Classic, the metadata status can internally mark images as "Has been changed" under certain conditions, even when the user hasn't made explicit edits. This can stem from internal metadata reconciliation (e.g., minor schema updates between LrC versions, GPS precision changes, or face detection data syncing), which then queues XMP writes on exit.

Troubleshooting steps to try:

• Before closing LrC, create a Smart Collection with the rule Metadata Status > is > Has been changed. This will show you exactly how many images LrC believes need XMP updates. Look at what they have in common: file format (DNG, RAW, TIFF?), whether they have face data, GPS info, or were recently imported/migrated from another catalog.
   

  

   

• Since the XMP writing itself is taking several minutes, that points to either a very large queue of files or slow I/O. If your catalog references files on a network drive (NAS), an external USB drive, or a cloud-synced folder, that significantly increases write time. Try temporarily moving a subset of flagged files to a local SSD and see if the exit delay drops.

• I know this sounds counterintuitive, but if you enable "Automatically write changes into XMP" under Catalog Settings > Metadata, LrC will write XMP incrementally during your session rather than batching at exit. This won't fix the issue of why images are being flagged, but it would eliminate the exit delay and let you observe in real time when/how quickly images are marked as changed (via the Smart Collection above).

• If you recently upgraded LrC, some internal metadata fields may have been updated schema-wise (e.g., new process version compatibility flags), which marks everything "dirty." A one-time CMD/CTRL+A > Metadata > Save Metadata to Files during idle time (with the app on a local catalog/local files) would flush that queue on your terms rather than at exit.

• Under Identity Plate (top-left), you can see if background tasks are active. Face indexing and reverse geocoding both silently modify metadata. Pause these if you suspect they're contributing.

  

   

To help me investigate further, a few questions:

• How large is your catalog (approximately how many images)?

• What file formats do the majority of your images use (DNG, proprietary RAW, TIFF, JPEG)?

• Where are your image files stored: local internal drive, external drive, NAS, or a cloud-synced folder?

• Did this behavior start after a specific LrC version upgrade, or has it always been present with this catalog?

• Do you use face detection or map/GPS features in Lightroom Classic?

• If you create the Smart Collection described above, approximately how many images show as "Has been changed" after simply opening the catalog without making edits?

The answers will help determine whether this is a one-time migration queue, an I/O bottleneck, or the metadata status affecting certain file types.

I appreciate your patience. I want to make sure we get to the root cause.

Best,

Anshul Saini