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.

[John R Ellis]

"Funny as I don't have a recipe other than starting up LR. Without even going into published collections, they change."

Yes, of course, those are the symptoms I'm experiencing too.  The goal of providing a recipe is to narrow down the conditions that are triggering the bug and make it easier for Adobe to reproduce and diagnose it, making it more likely the bug will get fixed sooner.

I've already expressed my opinion (twice) that it would be best if Adobe engineers took copies of our catalogs and debugged the problem, considering that the recipe above doesn't reproduce all the symptoms being observed. But unfortunately, Adobe usually does that only for hard-to-reproduce bugs that many more people are reporting or bugs that severely corrupt catalog data.  So even though I would prefer that Adobe devote more resources to quality assurance, for problems I care about I'm still going to post information and recipes that might accelerate getting the bugs fixed.

[John R Ellis]

I installed LR 10.4 and 11.1 on a new Macbook Pro (2021) that never had Creative Cloud on it before.  The recipe I posted above also reproduces the problem on this system. Here's a screen recording:

https://www.dropbox.com/s/q7lwcc4tt9f2cof/Publish-bug.2022.01.27.mov?dl=0 

[Rikk Flohr: Photography]

Distilling this down further:

"9. Select the two photos and do Library > Previews > Build 1:1 Previews.

10. Observe that the two photos now incorrectly appear in Modified Photos To Re-Publish."

This is where the disconnect is occurring.  Should the rebuild of a preview when there has been an underlying change with the masking tools used initiate a Republish? I could argue yes. The preview is now current, but the published file was rendered under the previous masking toolset and out of date.

Or am I missing something here?

[DVABAU]

Clearly, there are different degrees of severity with this issue as you are teasing out some small element of a suspected recipe to make it happen on a particular machine and I just need to go into LR and do NOTHING, to have the issue. While I appreciate the effort, if the root cause is the same, then it seems unlikely that teasing out a flaw in this recipe will make any difference at least certainly in my case.

[John R Ellis]

"Should the rebuild of a preview when there has been an underlying change with the masking tools used initiate a Republish? I could argue yes. The preview is now current, but the published file was rendered under the previous masking toolset and out of date."

Upgrading from 10 to 11 preserves the exact appearance and settings of individual graduated filters, radial filters, and adjustment brushes (unless they use color or luminance range masks). Re-rendering a photo that uses these produces the same exact result. Since the settings and visual appearance haven't changed, upgrading shouldn't trigger Modified.

[Rikk Flohr: Photography]

I've got the team looking at this thread and have also asked them to chime in on whether a preview re-render triggering a Republish is as designed behavior or not. 

I've been running an experiment for a couple of weeks on my home catalog and have yet to see an untouched image show up for Republish. 

[John R Ellis]

Another way to think about this: LR/Camera Raw maintain the invariant that for a given process version and settings, a photo should always render exactly the same.  They promise the user that a cataloged, developed photo will always re-render the same, until the user explicitly changes the photo (e.g. changes the process version).   That's why we don't need to export rendered JPEGs back into our catalogs.

[DVABAU]

As much as I now hate the idea of even going into my published collections because of this issue, I needed to go in an remove some photos. Once I selected a shot, it took about 30 seconds for the system to flag 55 photos for replublishing. What a PITA especially when I actually do edit a few shots as I have to remember the onces that did indeed change. I never left the Library module.

[Rikk Flohr: Photography]

Was in discussions - moved to bugs and cross-referenced with previous forum's threads and bug report. 

[Roger Buckingham]

I have this issue too. It has only started happening recently but I note that many of you have had this issue for a long time. It is very annoying.

[tomtel49]

Annoying is an understatement.   I finally quit worrying about it after long attempts to fix, repeated republishes and trying (as loggested by a LRC site) the "Mark as Up-To-Date" option - which did not seem to fix the issue.

HOWEVER using the current version of LRC 11.3.1 with Camera Rawe 14.3  - the problem has seems to gone away for the most part - I really cannot say for sure since the large amounts of photos with issues seems to have gone away, howeve had a few straglers that needed to be re-published (maybe less than 5% of what I had before) so not sure if these were something I opened and maybe made a change to or something along those lines.  Bottom line - don't have the issue happening enough now to even notice.   

Never received or saw any notice about this being fixed, so this is just an observation of recent changes I have seen.

Hope this helps you. 

[majak534737]

Hello,

I use Lightroom classic 11.3.1. I have s smart collection that shows me files with changed metadata. I select the files for which I want to save the metadato to disk, click on the icon "Metadata file needs to be updated" and save. I don't get any errors, metadata is saved. And the next second, the files reappear in the collection, again with the icon "Metadata file needs to be updated" . I did not do anything. Not even looked at the photo, moved from the Library, nothing. I was just watching the files desappear from the "metadata changed" smart collection and then reapear after a second. If I save the metadata for a few hundred photos, some of them wil reappear right back. And always the same files. I tried adding keywords and saving again, but it didn't work. The moment I save them, metadata is changed again. So what metadata is being changed?

[Ian Lyons]

>So what metadata is being changed?

Nothing has changed. There are similar reports to yours on the forum going back mnay years. It's a bug that Adobe don't seem able to find a permanent fix for.

[alexskunz]

There's a new problem with this in Lightroom Classic 11.4 and I'll try to explain it:

For files that WOULD be affected by this (ie. getting marked as changed & to re-publish as soon as they're opened in Develop, without actually making any changes), local adjustments won't be rendered correctly.

For example, I find an older file in the Library grid and export it from there (right-click, choose an Export preset). Local adjustments to that file are NOT rendered correctly. Switch to Develop, do NOTHING in Develop, export the same file again: now the local adjustments are rendered correctly.

Doesn't sound too bad, but consider this:

Making changes to say, titles, captions, keywords alone and then hitting "Publish" in a Publish collection, the files will be rendered wrong. One would have to additionally open each of these files in the Develop module so that LRC silently updates whatever it is updating under the hood for these files.

I can provide examples, if needed.

Alex.

[PhilBurton]

Adobe,

John has done all the hard work for you.  Why the continued resistance?  This bug is irritating. 

Why not accept the suggestion to have users upload their catalogs.  Else create a debug/trace mechanism that can capture this effect.

[Vivacious_Solace154A]

I have a number of photos in publish collections that I use to update a web site. The collections have been created by my own Publish Service plugin. Sometimes, but not always, selecting photos that are up to date in one of these collections causes the photos to be marked as requiring updating. There is no new entry in the dev history list when this happens. Has anyone seen anything like this?

[JohanElzenga]

Yes, there are several threads about this. One thing that seems to trigger this is when the thumbnail is out-of-date. Selecting the image will trigger an update of the thumbnail, and that triggers the update in the publishing service. Other cases are a mystery.

[Vivacious_Solace154A]

Annoying. Thanks.

[John R Ellis]

A frequent cause of this problem: When Adobe changes the internal representation of develop settings (without changing the process version), LR gets confused and thinks a photo as been "changed" and needs to be republished.  This happened in LR 2015.6 when Guided Upright was added, and again in LR 11.0 when the new masking was introduced.   Adobe has declined to fix this issue because there wasn't an easy-to-reproduce bug recipe and they didn't want to ask for people's catalogs to debug.

You can try these steps:

1. Select all the photos in a published collection.

2. Do Library > Previews > Build 1:1 Previews (to force LR to convert the internal develop settings to the new representation, which it normally does incrementally).

3. Select all the photos, right-click, and do Mark Up-To-Date.

This often didn't work with LR 11.0 and 11.1 -- there seemed to be a bug with Mark Up-To-Date. If it doesn't, your only option is to republish.

See this post for more details:

https://community.adobe.com/t5/lightroom-classic-discussions/photo-moves-to-modified-photos-to-re-pu... 

See these two threads:

https://community.adobe.com/t5/lightroom-classic-discussions/photo-moves-to-modified-photos-to-re-pu...

https://community.adobe.com/t5/lightroom-classic-bugs/p-photos-incorrectly-considered-as-quot-change... 

[John R Ellis]

Moderators, @Rikk Flohr: Photography, please merge with the existing bug report:

https://community.adobe.com/t5/lightroom-classic-discussions/photo-moves-to-modified-photos-to-re-pu...

[Peter-Strydom]

worked for me

[robertv47531707]

Prior to your last 2 upgrades I have not had any problems with this. Your last 2 upgrades have caused nothing but problems for photos being marked as "Photos to republish" even though they have not been modified in any way. The previous upgrade placed all my photos (11,000+) as being "Photos to republish." This latest upgrade now randomly marks photos to republish. I publish my photos to Flickr. When I drop some photos to publish to Flickr on the photostream line I now watch random photos placed in the "Photos to republish" area. This has been a complaint for many years. How hard is it to have an option that says "Do NOT republish photos?". This should be an individuals option. How many more complaints do you need to fix this? And what do I do now that I have to waste all my time tagging photos to "Mark as up to date?

[John R Ellis]

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

Problems with photos getting marked for republishing have come and gone over many years, and it's pretty clear that Adobe isn't going to fix the issues.  It's hard to provide a simple step-by-step recipe that reproduces the problem, but a few of us have offered our catalogs for debugging the problem.

For example, last month, I marked all my Zenfolio and Flickr collections as Up-To-Date.  And now, there are 4913 photos in 161 collections needing to be republished (all spurious):

I regularly use the Any Source plugin to remark them all as Up-To-Date using the button in the lower-right, since usually they haven't changed. But I know sometimes I've changed a keyword or caption, and that change won't get published because I've marked it up-to-date.

[runswithsizzers]

In my case, starting with an update to LRC 12.0, if I click on any photo that was previously published to SmugMug - some, but all photos - immediately jump up to the "Modified Photos to Re-Publish" area. See attached screen shot. Previously (before the recent update), some photos would randomly appear as "modified..." even though I had not edited them in any way.

[John R Ellis]

@runswithsizzers, unfortunately those are the symptoms that many experience.  I have over 5000 photos that keep getting marked as modified.  I mark them up-to-date, and then a day later they all get marked as modified again.  Same as in LR 11.