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

[Dr. Fred Mbogo]

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.

[bittern1]

Still no change even with the latest update.  There appears to be no logic whatsoever as to what photos are marked for republishing although it normally starts with a review of various images but whose metadata etc has not been changed in any way?

[Kim Kruse]

The constant republish issue seems to be even worse in version 14.1.1. Rebuild of previews does not help.

It makes the Gallery functionality worthless.

[kimaldis]

It seems to be more or less behaving for me. I've had a few that initially appeared marked to repbublish for no appparent reason but afterr some thought I remembered that my export plugin adds keywords to images it exports and the marked images seem to tally, from memory.

I've been doing a lot of work pulling together photos for a book which involves messing with * ratings and it's a bit of an annoyance that changing ratings marks for re-publish but on the other hand, it does seem reasonable. An exclusion list for publishing might help that, maybe.

[kimaldis]

Sod's law is in force, apparently. It's just started happeneing to me, but. for the first time it's happening right in front of my face. It seems to hinge around selecting and viewing images in grid of full frame. Has this been covered already? I don't know but just in case I did made a video showing exactly what I was doing: Mark to Republish Issue 23-12-2024.mp4

[johnrellis]

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

@kimaldis: "it's a bit of an annoyance that changing ratings marks for re-publish but on the other hand, it does seem reasonable. An exclusion list for publishing might help that, maybe."

Some publishing services let you control which metadata fields will trigger republishing, e.g. all of Friedl's publishing plugins:

[johnrellis]

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

@kimaldis: "It seems to hinge around selecting and viewing images in grid of full frame."

Your screen recording shows the pattern.  When you view an image in Loupe view ("e"), the next photo in the original custom order appears in Modified photos To Re-Publish. (See the screen grabs below.) Here's why this pattern is likely occuring:

One of the conditions that triggers this spurious republishing (there may be several) is upgrading to a new version of LR, where the new version changes the catalog's internal representation of Develop settings. When you do the catalog upgrade, LR doesn't change all Develop settings at once -- rather, it does it incrementally, typically when it needs to re-render an image. 

When LR upgrades a particular image's Develop settings to the new representation, it mistakenly thinks the Develop settings have changed in a way that affects the visual appearance of the photo (i.e. as if the user had changed a slider), which triggers the republishing.

In your screen recording, when you view an image in Loupe view, in background LR renders the next image in the custom order, as part of its strategy of making sure the next few images you might view will already be pre-rendered and cached in memory, ready to go when you select the next image . That rendering then triggers the upgrade to the internal representation of the Devleop settings, which triggers the republish.

You can often force the upgrading of Develop settings to occur all at once by selecting all your photos, doing the menu commands Library > Previews > Discard Standard And 1:1 Previews, and then Library > Previews > Build Standard-Sized Previews (and then letting LR run overnight if the catalog is large).  Then you can select all the photos needing republishing, right-click, and do Mark As Up-To-Date.

But that recipe isn't guaranteed to work. In the past, Mark As Up-To-Date hasn't always "stuck". And there is some evidence that there are other conditions (bugs) that triggered spurious republishing.

This thread dates from 2020, but the general problem of spurious republishing long predates that. The problem seems to be not occurring for many of us in LR 14, but there are a few reports like yours that it still occurs. In the past, Adobe didn't appear to make much effort in address it.