Participating Frequently

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

Forum|Forum|5 years ago
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.

Show previous replies

A

Aaron Roberts

Inspiring

Just to add to my last comment. Even marking all photos to republish and then ACTUALLY re-publishing them all, does not solve the issue. Even if the entire collection was published 5 minutes before, scrolling through the images will randomly mark images to re-publish again.

A

Aaron Roberts

Inspiring

I also have this issue for YEARS. It seems that Adobe are doing sweet FA about it and it's driving me nuts. Some of the publishing services I use will overwrite the "published" files, in other cases, it'll simply just keep adding to the published files.. resulting in duplicates of images which are already publish and have NOT been edited.

About half a year ago, I posted a videon on this also: https://youtu.be/E92STPHYemE

There have been numerous updates to LrC over the past months and yet this bug still remains. It even seems to get triggered by simply re-generating previews. I fricking hate it!

D

DVABAU

Participating Frequently

Yes that works if you also haven't been editing otherwise, your changes won't be published. I'll often do this before I start editing and hope that by time I done there aren't that many more that get added.

Regards,

Dana

alexskunz

Inspiring

@Jonathan25940150zxd9you can mark all photos in the "modified to republish" section as "up to date" (Cmd/Ctrl+A, then right-click) so that you don't have to actually re-publish if they haven't changed.

johnrellis

Legend

@Jonathan25940150zxd9 wrote, "So if I want to go back and add a keyword tag or pretty much anything, it's impossible to do until I republish the album."

Can you say more about this? You can add keywords to photos needing republishing.

J

Jonathan25940150zxd9

Participant

Pretty much anytime I open an album Lightroom moves all of the pictures (very slowly) to 'modified re-publish'. So if I want to go back and add a keyword tag or pretty much anything, it's impossible to do until I republish the album. This makes lightroom almost useless for me. I've noticed that there are never any posts from Adobe. Is this actually a support group owned by Adobe or just a place to complain about the problems we find? I'm getting the feeling that they have the market so dont' really care about customer service.

D

DVABAU

Participating Frequently

Trust me, there is no rhyme or reason, it arbitrary marks things to republish regardless of my activity or lack thereof.

D

doug_bailey

Participant

I'll add my "me too" to this chain. I've been digging into the symptoms a little bit tonight, and I've got an interesting way to reproduce the problem.

I'm working with 12.0. I flushed out a published-to-harddrive album (marked everything to republish, deleted the contents of the directory on the harddrive, then republished the album). Grid mode viewing the album and everything is marked as published. Examine one of the photos, zoom in to 100%, zoom back to "fit". Switch back to grid mode. That one photo is now in need of republishing. I reproduced this a bunch of times, but it doesn't seem to happen every time.

H

helennium

Known Participant

This is outrageous. I'm encountering the bug, too, and when I looked it up I found this discussion. It's been going on for years. I guess the publish to Flickr module in Lightroom is essentially useless. I do not want to sit here modifying the publishing dates for over 600 photos.

alexskunz

Inspiring

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.

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded