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
  • 19975 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

e.j.v92227290
Participating Frequently
September 10, 2023

Adobe... are you reading posts in this forum? I'm thinking and hoping you do. Can you confirm that this bug is on your list of issues to be addressed please?

e.j.v92227290
Participating Frequently
September 2, 2023

Note that rebuilding previews and then setting the entire collection as published might (or might not) work, in any case it will trigger all files to be backed-up again (and that's a few 100 Gb for me...). Maybe a possible temporary workaround but not the solution we need obviously 

e.j.v92227290
Participating Frequently
August 29, 2023

Posted in "The Lightroom Queen" forum and now posting here.

 

I've been using Jeffrey Friedl's great "Folder-Publisher" add-in for years now, as it allows me to create an identical parallel folder structure with all my photo's exported as JPGs with all my edits applied.
There's one problem however which, as Jeffrey also told me, was raised for many years and several times already to Adobe, but seems to have remained unaddressed since the perpetual LR version era years back.
As I can't formulate it better than Jeffrey does in one of his blogs, here's his description: "Sometimes photos just spontaneously move from “Published” to “Modified Photos to Re-Publish”, regardless of the settings in “Metadata that Triggers a Republish” and regardless of what's actually been changed."
As you can imagine, this largely defeats the whole publishing purpose. I have 22K+ photos and if I make a few changes and want to update my JPG folders, instead of a quick publish, sometimes 800 extra pictures I never touched (but maybe viewed? I'm not entirely sure) are added. So now the publish process takes a much longer time (plus my system backups later include these uselessly updated photos as well).

Please Adobe, I'm seeing that many users have been reporting this for many years now. This completely defeats the who Publishing functionality. Can you please investigate, debug and fix this problem and make us all happy? 

Inspiring
August 28, 2023

Sounds like you may have bigger issues. The problem is, you shouldn't have to re-render anything. There should be a simple "flag" which indicates if a photo (regardless of its preview) has not been modified since the last time it was published.

That flag is broken and has been for years.. At this point it's just plain negligence on Adobe's part.

aliceinwl
Participating Frequently
August 27, 2023

Re-rending the photos solved that porblem! But, now my catalog keeps getting corrupted for some reason: probably unrelated.

Participant
August 17, 2023

On 8/13 through the insistence of  Adobe support on the phone with me, I removed my Flickr link service to LRC and reinitiated it.  I am pleased to say to date I haven't had any random republishing events in my Publish Services for Flickr. (Mac Computer)

alexskunz
Inspiring
August 17, 2023

@johnrellisquite honestly, I'm surprised that this problem hasn't reappeared for me 😅 but so far, so good. 🤞

 

I'm wondering whether it might have to do something with the preview cache itself. As I mentioned, LRC decided to nuke my entire preview cache after a system migration.

alexskunz
Inspiring
August 17, 2023

@aliceingdid you already try letting Lightroom Classic re-render previews for all photos in the entire Flickr collection?

 

Cmd/Ctrl+A, menu Library, Previews -> Render Standard-Sized Previews.

aliceinwl
Participating Frequently
August 17, 2023

I was really hoping there was a solution to this. I have over 20,000 photos in my Flickr collection. Ever since I upgraded to Lightroom 11, every time I go to publish new photos or republish select old photos Lightroom starts pulling up random photos from my catalog by the 1000s. Republishing them doesn't help and telling Lightroom the photos are up to date only helps temporarily. Even marking them up to date is like whack a mole because Lightroom keeps pulling up more photos by the 100s as fast as I can mark them. It's hugely frustrating 😞

johnrellis
Legend
August 15, 2023

"I'm mentioning this because having LR render Standard previews for all published photos in a collection seems to update whatever metadata change triggers this."

 

Glad that's working for you.  Forcing LR to re-render previews hasn't helped me and others in this thread, unfortunately.