Participating Frequently

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

Forum|Forum|5 years ago
October 25, 2020
112 replies
19971 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

DClark064

Inspiring

I found it. dj_paige reported Friedl's Smugmug did not show the problem, https://community.adobe.com/t5/lightroom-classic-discussions/lightroom-creates-duplicates-when-republishing-to-flickr/m-p/14842733#M378235

That's another thread that should probably be merged with this one.

johnrellis

Legend

These symptoms have been reported for many different publish services (each with its own plugin). Personally, my Flickr (Adobe plugin) and Zenfolio (Friedl plugin) services are affected. There's a report about Smugmug, though it doesn't specify which plugin. I'd be very surprised if the Friedl Smugmug plugin didn't experience the same problems.

DClark064

Inspiring

Does anybody know if using Friedl's Smugmug publish module eliminates this issue?

I believe I saw someplace that it did but I don't want to read seven pages of posts.

johnrellis

Legend

@robertv47531707: "And you don't think anyone from Adobe reads these forums?"

Senior Adobe employee Rikk Flohr actively moderates this forum and curated this thread, linking it with the internal bug report.

R

robertv47531707

Known Participant

And you don't think anyone from Adobe reads these forums?

R

robertv47531707

Known Participant

2+ hours marking "modified photos to republish" as being "up to date." No rhyme or reason again for this. Fixed a photo and then went I to the Flickr Photostream tab and all kinds of random photos started streaming in to "republish." I would highlight them and mark them as "up to date" and then another random batch of photos would be there to "republish." This went on for 2+ hours. This is a known bug for quite some time , but the "engineers" can't fix it nor are they capable of placing some kind of button so the user can determine when to republish a photo.

dj_paige

Legend

This is mostly a user-to-user forum. We have no control over what Adobe does, and posting here accomplishes nothing.

K

kimaldis

Inspiring

Latest incarnation of this, I've dragged a bunch of new photos into a publish service collection and notice that every photo that's already in the collection has been marked for republish. So I hit the publish button and everything, exisiting and new, gets published. So now I start ordering photos in the collection and every time I select one of the photos I've just published it gets marked for re-publication. Even though no change has been made. Which, as you can imagine, makes it nigh on impossible to re-order photos.

4 years now that this bug has been floating around. If it was just something niggly I'd probaably be less bothered but this is now a major workflow issue for me and frankly, I'm bloody annoyed. The advantage for me with Lightroom has always been its workflow. That advantage is rapidly eroding.

B

bittern1

Participating Frequently

I am having exactly the same problem with photos on the Flickr transfer publisher being marked for republishing on a more or less continuous loupe. The problem seems to have worsened since the recent update (13.3.3) to LR Classic. I have also recently renamed my two catalogues. I contacted Adobe Help but just received a load of unhelpful input - blaming Flickr - from the Adobe Bot which then tried to charge me £1 (refundable) to talk to an expert.

Come on Adobe please "digitus extractus" and get this matter resolved!

Califdan2

Inspiring

In may case I can select all the images in the to be modified section and mark them as uptodate. Then whith my hands in my pockets I watch them all go to the "Published" section and then a second later some of them pop right back up to the "Modified" section. Some specific images do this every single time in every single PS collection.

K

Kim Kruse

Participating Frequently

Currently it seems in my setup that requesting re-build of 1:1 previews for all photos followed by "Mark Photos as updated" solves the issue.

One thing is that going fron version 13.2 to 13.3 requieres rebuild preview (which will be done allready when zooming on the photo in Library module), but it should NOT change the change state to "Re-plushing".

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