P: Save Metadata To File doesn't change metadata status, Read Metadata From File doesn't always work

Could be related to this one - 

Lightroom Classic: Save Metadata To File doesn't change metadata status, Read Metadata From File doesn't always work

Since the update to Lightroom Classic Version 10 reading crop metadata from .XMP sidecar files for .NEF RAW files fails reproducably. 

My workflow is as follows: 

I ingest all my .NEF files with Photo Mechanic which writes .XMP sidecar files to the .NEF RAW files. It adds IPTC metadata information on a usual level like description, headline, keywords, event, location etc. Nothing unusual here.

After ingesting I still use Photo Mechanic for image culling where I assign the star rating (1 up to 5) and do some cropping which is faster than in Lightroom Classic. Afterwards I switch to Lightroom Classic and synchronize the folder by right clicking on the folder in the Library module. I let Lightroom search for new pictures and changes in the metadata. After that it shows metadata conflicts for the photos where I did metadata changes in Photo Mechanic.

The following step was working for many years in Lightroom Classic: I let Lightroom read all metadata for the conflicted files from the .XMP sidecar files (clicking "Read Metadata from File"). These hold star rating and crop information. This data was always updating in Lightroom perfectly well without any issues. Now since Version 10 Lightroom updates only the star rating. All crop information or color codes are not updated in Lightroom catalog at all on "Read Metadata from File". This is a bit annoying as it was working perfectly fine for years prior to V10.

What works instead ? If I remove that folder which holds the photos with changed crop metadata from Lightroom catalog and let this folder be imported again into Lightroom it imports all metadata perfectly fine again. Not only star rating but also color labels and the expected crop information shows up correctly in the lightroom catalog. All that is quite time consuming as Lightroom is creating the preview and smart preview data again.

I additionally checked Adobe Bridge here as well. It is working perfectly fine. When I access photos with .XMP sidecar files with crop information it shows that even in its previews correctly. So everything is fine with Adobe Bridge.

Just as a side note here: The behaviour of Lightroom was exactly the same for photos stored on local hard drives or NAS drives.

There were only .NEF and .XMP and no JPG files in these folders.

Versions currently used here:
Lightroom: Version 10.1.1
CameraRaw: Version 13.1
Adobe Bridge: Version 11.0.1.109

It seems that Lightroom does not respect the following crs: XML tags when the metadata is intentionally read back from the .XML files: These tags are added by Photo Mechanic. The crs: tags are common and look reasonable in the .XML as the following site suggests: https://www.adobe.io/open/standards/xmp.html#!adobe/xmp-docs/master/XMPNamespaces/crs.md

   crs:HasSettings="False"
   crs:AlreadyApplied="False"
   crs:HasCrop="True"
   crs:CropLeft="0.049250"
   crs:CropTop="0.049164"
   crs:CropRight="1.000000"
   crs:CropBottom="1.000000"
   crs:CropAngle="0.00"
   crs:CropUnit="3"
   crs:CropWidth="3.000000"
   crs:CropHeight="2.000000"
   crs:CropConstrainToWarp="0"

When a photo is not cropped by Photo Mechanic it does not have these crs: tags in it.

Thanks for some comments if someone else can reproduce this. In my case this behaviour persist since V10 and is  reproducable each time. It is definitely not related to Photo Mechanic as this was not updated for a longer while and reading the crop data works if photos are freshly imported in Lightroom. Only reading metadata from files fails for crop metadata.

I feel this is a bug in Lightroom and I do hope someone can chase it down and if approved create a bug entry for Lightroom classic V10.

I can provide some example and sidecar files for that issue if needed.

Thanks a lot,Heiko

Thanks for the details.

Hi John. It goes away but usuallycomesback again. Sometimes all it takes is to go in to Develop mode - do nothing - and come back to Library and that makes it come back. 

Today I went to close LR after it sitting idle for about 4-5 hours and got a message that said changes hadn't finished writing to .xmp yet. I had done very little work today and it had sat for hours. What did it still have to change for Pete's sake? Should have finished hours before. 

All of these metadata conflicts and issues just started very recently 

Andy, when you select a photo whose metadata-status badge indicates a conflict or that the catalog data needs saving to disk and do Metadata > Save Metadata To File, does the status badge go away, or does it often come back?

RIKK - does NAS storage make a difference in this? I'm having similar issues with unresolved changes and have recently moved to a NAS.

Why conversations get merged:

https://feedback.photoshop.com/conversations/lightroom-classic/lightroom-auto-import-to-folders-organized-by-date/5f5f44f14b561a3d422ab0ba?commentId=5f5f48984b561a3d422bdf45 

Are the 'stubborn' files stored on a NAS?

I have a smart collection in Lightroom Classic v10 (Windows 10) to gather images I've made changes to but have not saved (I do not auto write changes to XMP). When I'm ready, I open this collection, select all the photos and do Ctrl-S to save metadata to file. Usually this works fine.

Sometimes the save happens but LRC still tells me the metadata has been changed in LR but not saved. So I select again and choose Metadata>Read metadata from file. Often this works and the images clear the collection.

However, sometimes I have "stubborn" files that no matter how many times I repeat the above steps the metadata remains unsaved. And this can be pictures that I have not changed in my recent session, just opened the folder where those files reside.

Even after quitting LRC and shutting down the computer overnight, the "unsaved" images remain. This has continued with various photos through multiple LR upgrades.

I appreciate any thoughts/suggestions.

Thanks!

"this appears to be an issue that only affects BW images."

It also affects raws with non-zero crop angles. See the first reply above.