P: Constantly "saving xmp for xx photos" slowing down my Lightroom Classic!

Aftershoot reads and then modifies LR's XMP files. User needs to initiate Read XMP Files in LR to complete the task.

@JohnVPhotos , Ok understand but why would it trigger LrC to Read Metadata from XMP?

Aftershoot is a stand-alone app for culling and editing but works with LR.  It works with LR via its XMP files - hence the READ and WRITE of the XMP. Right now I'm using the culling side of the app. The app is super useful for me when shooting galas and events where repetitive frames are needed such as group shots. For instance I'll take 5 frames of a 10 person group. Aftershoot will scan all 5 frames and choose the best frame based on eye-blinks and focus. The app has saved me tons of culling time.

https://aftershoot.com

@JohnVPhotos , you stated "I'm using Aftershoot to cull my images. Aftershoot updates the .xmp files after it's cull, that's when "Read Metadata from File" comes into play."

Is Aftershoot a plug-in for Lightroom Classic?

Thanks everyone for troubleshooting this issue. The fix is turning "Automatically write changes to XMP" to off. I've shot a number of events since and have not had a slowdown. Though I still think it's a bug!

Thanks again!

John V.

I wanted to add something that I confirmed by additional testing, since we now know how to trigger excess XMP updates. I originally wrote:

"I had been syncing about 500 photos to the cloud until recently, but noticed (by watching Sync Activity in Preferences) that sync kept looping repeatedly through photos it had already synced (and I hadn't edited).... Now I wonder if repeated syncs were getting triggered because of the excess XMP updates."

This morning, I turned "Automatically write changes to XMP" off and synced the collection I'd been using for testing. With this setting off, sync behaves normally -- each image gets synced as it's edited and there are no repeated syncs.

Then I turned "Automatically write changes to XMP" back on and edited three of the collection's photos. After that, the three photos kept re-syncing to the cloud every time I use one of the methods we found that unnecessarily updates XMPs, like moving between Develop and Library, selecting another image in the filmstrip, or just mousing around. This continued until I switched to a different collection (when Lightroom synced them one last time).

That this would happen may be obvious, but I wasn't sure if there was a relationship so wanted to see if I could make it loop both XMP updates and syncs -- and it did!

This might also be related to the other bug that adds history steps for just going into develop while not making a single change. 

@Junction10Photo: "I've not had chance to do the full screen recording you suggested"

I don't think that's necessary, now that @daleducatte identified a simple recipe for reproducing the problem.

"have you tried to see what changes are being written to the XMP file?"

I did -- the only fields that changed were MetadataDate, an industry standard field recording when the metadata was last written, and InstanceID, identifying the unique instance of that metadata. These get changed whenever the metadata is written.

I think the two recipes indicate the internal comparison method for determining when metadata has changed is completely broken. I believe the recipes may be triggered by a longstanding LR heuristic where it gives priority to re-rendering library previews of changed photos whose thumbnails are currently being displayed in the filmstrip and grid view (deferring other changed photos until later). As part of that re-rendering, it may also be checking if the metadata has changed and needs to be written to disk.

diff 1.xmp 1\ copy.xmp 
35c35
<    xmp:MetadataDate="2024-09-08T08:12:08-07:00"
---
>    xmp:MetadataDate="2024-09-08T08:11:18-07:00"
47c47
<    xmpMM:InstanceID="xmp.iid:a59c9467-74e9-4ca4-9a99-1aae1d0cc160"
---
>    xmpMM:InstanceID="xmp.iid:6f5b4f63-36bb-48c7-be49-06ad64986d6b"
164,165c164,165
<       stEvt:instanceID="xmp.iid:a59c9467-74e9-4ca4-9a99-1aae1d0cc160"
<       stEvt:when="2024-09-08T08:12:08-07:00"
---
>       stEvt:instanceID="xmp.iid:6f5b4f63-36bb-48c7-be49-06ad64986d6b"
>       stEvt:when="2024-09-08T08:11:18-07:00"

@daleducatte: "In step 9 above, did you mean to say "go to Develop" rather than "go to Library"?"

Thanks, I corrected it.