Skip to main content
Participating Frequently
October 25, 2020

P: Photos are marked for republish even though there is no change.

  • October 25, 2020
  • 112 replies
  • 19974 views

I noticed after updating my new v10 converted catalog that LrC was acting slow in the Library module, so I disengaged the usual culprit for this, the "Automatically write changes into XMP" setting. Then to my dismay, I noticed that it proceeded to mark the majority of the photos in the current grid view as needing a metadata update, even though the catalog metadata was fully saved to XMP prior to the upgrade, as far as I was aware.

 

Then I paged down, and the pattern repeated: Lightroom scanned all the now-visible photos and found that almost all of them also needed to be updated on disk.

 

And I did it again. And again.

 

Eventually I wrote a script to send "Page Down" events to the program periodically to ensure that Lightroom looked at every photo in the catalog, then let it run overnight with the library filter set to "Metadata Status = Up to date", so that it would give me the list of photos that need no metadata update. The next morning, I scrolled the grid back up to the top and let it go again, to catch any photos it missed on the first pass.

 

In the end, it marked over four-fifths of my catalog as out of date. This beggars belief, since I normally keep "Automatically write changes into XMP" engaged.

 

Then I did an experiment: I ran exiftool on one of the photos marked as still needing an update, saving the result to a text file, told Lightroom to save the metadata (⌘-S) and ran exiftool on the result, saving the output to a different text file, and diffed the two outputs, and found only timestamp and program version differences!

 

Observe:

 

5c5< File Modification Date/Time     : 2020:10:23 18:31:53-06:00---> File Modification Date/Time     : 2020:10:25 10:46:00-06:007c7< File Inode Change Date/Time     : 2020:10:23 18:31:53-06:00---> File Inode Change Date/Time     : 2020:10:25 10:46:00-06:0026c26< Instance ID                     : xmp.iid:9acec219-b6a4-4918-a592-9fc6a0ab3486---> Instance ID                     : xmp.iid:b5e76784-9638-44a1-a8b6-4e17799d003f28c28< Metadata Date                   : 2020:10:23 18:31:53-06:00---> Metadata Date                   : 2020:10:25 10:46-06:0040,41c40,41< History Instance ID             : xmp.iid:eac2ee0b-0b2d-4143-8da1-cafb424d66cc, xmp.iid:9acec219-b6a4-4918-a592-9fc6a0ab3486< History When                    : 2014:04:27 20:29:30-06:00, 2020:10:23 18:31:53-06:00---> History Instance ID             : xmp.iid:eac2ee0b-0b2d-4143-8da1-cafb424d66cc, xmp.iid:b5e76784-9638-44a1-a8b6-4e17799d003f> History When                    : 2014:04:27 20:29:30-06:00, 2020:10:25 10:46-06:00

 

For that particular file, the "Metadata Date" inside Lightroom is in July of 2019!

 

You may then wonder why the file modification time in the diff isn't in 2019, but instead two days ago. I dug into a recent pre-upgrade backup of my photos, and indeed, the prior file's mtime was in 2019. So, not only did LrC v10 decide it needed to do a bogus update to the file's metadata, it touched the file prior to actually being told it was okay to do so!

 

This upgrade has entirely invalidated all of my photo backups. Everything has to be backed up again, all because LrC is being stupid about touching files unnecessarily.

 

Surely the only defensible case for updating the application version number in the file's XMP metadata is that I've changed the photo, so now the program is properly reporting the last application to update the metadata?

 

I see other posts in the forum here on related topics, such as complaints that publish services are forcing a re-publish of unchanged photos. I'm posting this because I think I've diagnosed this to a deeper level than most users.

112 replies

Schmidtze
Participating Frequently
October 28, 2020

I forgot to mention again, that after saving the metadata manually to the DNG files, they will appear again and again as changed. So that's of course a bug...

Best regards

Friedemann

Schmidtze
Participating Frequently
October 27, 2020

But I checked the difference which has been written, it's nothing important, no development change, it's simply the new xml version of LR 10 and a date. That's absolutely not necessary, to invalidate thousands of files. Also in the cloud, for me about 40.000 files had to be uploaded and downloaded again on my devices...

Known Participant
October 27, 2020

Hi did the library module speed up for you once you did that, for myself and other users (see other threads) it is being very slow post v10 and looking for a fix?

Victoria Bampton LR Queen
Community Expert
Community Expert
October 27, 2020

> It blows my mind that Adobe can boast about LR being a parametric editor that doesn't touch original images while in fact it is constantly modifying original files.

I fully support the request for sidecar files for all formats, however modifying the metadata of the originals files is completely optional, and was only made available for cross-app compatibility. Automatically write to XMP is not enabled by default and you can leave it turned off if you don't want to modify your originals.

Victoria - The Lightroom Queen
kimballisms
Inspiring
October 25, 2020

Strongly agree.  Sadly I believe this argument has been made many times before, and Adobe continues to think their method of re-writing our originals is the right way.

Participating Frequently
October 25, 2020

Yes, there should be an option for "external XMP" with JPG and DNG, not only to solve problems like the one in this thread, but also because it would keep my ZFS snapshots and external backup deltas small. It'd probably be quite a performance improvement to the Library module as well.

Participating Frequently
October 25, 2020

Yes, I've seen that symptom as well. I reported it separately as point #4 in this post.

Participant
October 25, 2020

There has been some seriously digging into this ancient flaw during the years. I wish I could provide you a link to some of the threads, but the consensus is that it's a bug in how LR handles it. Something that your research seems to validate. 

I'm so tired of how increasingly buggy this software has become... 

With your apparent knowledge please try to locate the other threads - hopefully some rock solid evidence can come out of it which might make Adobe move their apparent lazy and ignorant asses someday...

kimballisms
Inspiring
October 25, 2020

This upgrade has entirely invalidated all of my photo backups. Everything has to be backed up again, all because LrC is being stupid about touching files unnecessarily.

Ah, the joys of using DNGs and JPGs in Lightroom.

It blows my mind that Adobe can boast about LR being a parametric editor that doesn't touch original images while in fact it is constantly modifying original files.  Their hubris is off the charts.

Schmidtze
Participating Frequently
October 25, 2020

I had the same problem, that a lot of files have been marked as changed... For some files it was not possible to save the changes to disk. Immediately after doing it, it occured again as changed...

 

Strange!

 

Best regards

Friedemann