Legend

P: Scan For Metadata Updates causes spurious metadata conflicts

Forum|Forum|6 years ago
November 22, 2019
3 replies
151 views

Synchronize Folder > Scan For Metadata Updates can cause frequent spurious metadata conflicts for TIFFs that are stored on NAS.

Over the years many people have reported spurious metadata conflicts that Adobe hasn't been able to track down, and many of those reports involve photos stored on NAS. Here's a recent report:

https://feedback.photoshop.com/photoshop_family/topics/before_after_comparison_of_metadata_conflicts...

While the particular use case here may not be that common, it may provide a reproducible test case that points to the bug (likely a race condition) underlying all those other persistent reports.

Here are the steps that consistently produce the spurious conflicts in my configuration:

1. Connect to a network volume on a 2013 iMac running MacOS 10.14.6. The volume is mounted with SMB 3.0.2.

2. Place 4 1800 x 1200 TIFFs (about 13 MB each) in a folder on the network volume.

3. Import them with Add into a LR 9.0 catalog running on a 2019 Macbook Pro running Mac OS 10.14.6.

4. Select all 4 photos.

5. Do Metadata > Save Metadata To File.

6. Do Synchronize Folder with just Scan For Metadata Updates selected.

7. In the Metadata panel, change Caption to "a" (changing all 4 selected photos). Often, one or more of the photos are marked "Metadata has conflict".

8. Repeat steps 5 - 7, changing the caption to "b", then "c", etc. Observe the metadata conflicts that appear randomly on the photos.

Here are screen recordings showing this bug, with two different TIFFs:

https://www.dropbox.com/s/e78s6fudehcls95/sync-folder-spurious-2.2019.11.21.mov?dl=0
https://www.dropbox.com/s/9sz4nz3t3pmk2hc/sync-folder-spurious.2019.11.21.mov?dl=0

J

Josef Carlin

Participant

## Bug Report: "Update DNG Preview & Metadata" corrupts Linear DNGs on SMB Network Volumes (Synology NAS)

**Description of Issue:**
After updating to Lightroom Classic 15.4.1, executing the "Update DNG Preview & Metadata" command on a newly generated Linear DNG (created via HDR Merge, Panorama, or Enhance) living on an SMB network volume causes immediate file corruption. The file structure truncates, a black circle with an exclamation mark (!) appears, and the Develop module throws a "File appears to be unsupported or damaged" error.

This issue does not occur when modifying native read-only raw files (.NEF), as the adjustments live strictly in the catalog. It specifically occurs when Lightroom attempts to write directly into a DNG container file over an SMB connection.

**Lightroom Classic Version Number:**
Lightroom Classic v15.4.1 [ 202606101834-493069d4 ]

**OS Version Number:**
macOS 16.5.1 (or Windows 11 Pro)

**Storage Environment: DS920+ DSM 7.3.2 - 86009 Update 3 Latest Release**
- Synology NAS (4x8 TB drives in RAID/SHR configuration)
- Connected via SMB protocol
- Massive volume headroom: 4.2 TB photo volume with 2.8 TB of confirmed free space. (Rule out "disk full" or local permission issues).

**Step-by-step Reproduction Instructions:**
1. Store original raw files (.NEF) in a synchronized folder on an SMB-mounted Synology NAS share.
2. Select multiple .NEF files and perform a Photo Merge -> HDR to create a new Linear DNG.
3. Apply deep edits in the Develop Module (e.g., Transform settings, Super Resolution, or AI Generative Remove / distraction removal tools).
4. Return to the Library module, select the newly generated DNG, and go to Metadata > Update DNG Preview & Metadata.

**The Expected Result:**
Lightroom Classic successfully writes the updated XMP edit data and embeds a new full-size JPEG preview into the DNG container file over the SMB network path.

**The Actual Result:**
The write operation fails or gets interrupted mid-stream. The file header truncates. The image immediately gains a black exclamation mark icon (!). The image can no longer be edited in the Develop module ("unsupported or damaged"). Finder "Get Info" shows only the unedited original preview, proving the raw block behind the header was completely dropped or blocked during the write process.

**Troubleshooting Performed & Workaround:**
- Recreating the exact same workflow with other random images yielded identical file corruption every single time on v15.4.1.
- **The Definitive Solution:** Completely rolled back the software to **Lightroom Classic v15.3.1** and restored a catalog backup from June 22nd. Under v15.3.1, the exact same workflow (HDR Merge -> Heavy AI Edits -> Update DNG Metadata) executes perfectly on the exact same network folder over SMB with zero errors or file corruption. This confirms a distinct network I/O code regression introduced in the 15.4 file-saving layer.

johnrellisAuthor

Legend

Some more notes:

- Here are the photos shown in the videos:
https://www.dropbox.com/s/nsbtwasbydbs1qw/sync-folder-spurious.zip?dl=0

- The client machine was connected to the server via Google Wifi, pretty fast Wifi but not as low-latency and fast as ethernet. The higher latency may be more likely to provoke the supposed race condition.

- The iMac server, though plenty fast as a desktop, wasn't a speed daemon for NAS (likely due more to MacOS than the hardware). It's mild sluggishness as NAS perhaps may be more likely to provoke the supposed race condition than a faster dedicated NAS.

So to replice this issue, I recommend using an older desktop with rotating disk storage, using SMB over Wifi.

RackMultipart20191122814001j0t-874834c1-765d-4f00-800d-48f347567b8e-572082014.png