P: Photos incorrectly considered as "changed" by republishing and smart collections

Maybe I made a mistake. I'll try again and let you know.

No mistake. Changing the touchTime field has no effect on the membership to the smart collection.

There's another table, AgLibraryImageChangeCounter,  that has a date field : changedAtTime. It is not stored in the Cocoa format as the other time stamps in the database but as a string.

Not many images in that table and I can't make any connection with the image I'm testing. There's an image field that is obviously there to identify the image but I can't connect it to the rootFile field in Adobe_images or to the id_local field in AgLibraryFile.

Thanks, John. I'll have a look at this plugin. However, as explained above, I already tried to set the touchTime field to a date value that should exclude the corresponding image from the smart collection. This had no effect.

Maybe I made a mistake. I'll try again and let you know.

"Now I'm wondering which data LR is looking at when determining the last "edit" date. "

The SDK API provides access to a per-photo field "lastEditTime".  This appears to correspond to the Adobe-images.touchTime field in the database.  To test that, I took a several values of "lastEditTime" and searched for them in a text SQL dump of the database, and they showed up in the "touchTime" field.

You might find this plugin handy for seeing all the photo fields that are available to plugins: https://dl.dropboxusercontent.com/u/21811200/showmetadata.1.1.zip

This appears to be a very old bug, indeed :

https://forums.adobe.com/thread/1399404

I further investigated this case. I looked at the data related to an image unduly added to the "Last 7 days edited images". This is what I found :

Catalog
Adobe_Images table  / touchTime  field :  2017/02/12    17:32:41
AgLibraryFile table     / modTime field :      2015/05/16     11:57:04

XMP file
xmp:ModifyDate="2015-05-16T13:57:04.46"
xmp:CreateDate="2015-05-16T13:57:04.46"
xmp:MetadataDate="2017-02-16T09:48:06+01:00"

Only 2 time stamps could justify the addition of this image to the collection. So I have successively reset these fields to an older date (this requires conversion to the Cocoa date format). This had absolutely no effect. The image was still added to the collection.

Now I'm wondering which data LR is looking at when determining the last "edit" date.

I also tried to change the "last modified" Windows time stamp of the XMP file itself, resetting it to an older date. No change. The image is still in the collection.

Really strange.

PS : Those interested in playing with the time stamps contained in the LR database will have to convert to and from the Cocoa date format. You'll find an online converter here : https://blog.paddlefish.net/?page_id=90 .

See the previous post by Paige Miller with very similar symptoms: https://feedback.photoshop.com/photoshop_family/topics/modified-to-republish-problem?topic-reply-lis...

It's very possible that the issue with Guided Upright settings added in 2015.6, described here:  

https://feedback.photoshop.com/photoshop_family/topics/modified-to-republish-problem?topic-reply-lis...

is also causing LR to mark the photo as "edited" when it adds the new develop settings to the photo.  Or it could be a separate cause.

Hi,

Upon installation, Lightroom creates a set of sample smart collections. Among them the "Last 7 days edited images" and the "Last month edited images".

I'm wondering what "edited" means in that context since I can see in these collections thousands of images that I have not touched since years.

Since it appears that the bug is triggered by new versions of LR viewing images published by older LR versions, and re-importing the metadata from file messes with the Develop module 'before' state (and creates many unnecessary files), I think I've found a solution that works better for me - just edit all published images in the new LR version. This will update the metadata for all published images, preventing the Republish bug from being triggered.

This is what I did. One caution... Since this procedure temporarily modifies develop settings of all of your published images, the safest plan is to back up your catalog before starting. If LR crashes while applying edits in Autosync, you could end up with unwanted changes to all your published images. 'Undo' will reverse Autosync changes, but not after LR quits. So...

1. Select all the published collections in Publish Services.
2. Select all the images in grid view.
3. Go to Develop module
4. Engage Autosync (Be very careful with this setting: With Autosync engaged, every edit you make is applied to all selected image at once)
5. Carefully make one small change to a setting not used for any published image. (I chose Grain) If you are editing many published images, you may have to wait while the edit is applied to all the images. Look for the progress bar, upper left.
6. Immediately reverse the edit you just made, leaving the setting as it was before. Wait for change to apply to all the selected images. So now all published images have been updated to the new LR version.
7. Disengage Autosync! (very important. If you forget, future edits could be accidentally applied to all your published images)
8. Return to Library module
9. Go through each published collection and mark all images as up to date.

This seems to have solved the problem for me.

Incidentally, in my case (Smugmug LR plugin) published images were jumping up to Republish without even viewing them 1:1. All I had to do was scroll through the collections in grid view and images would be marked to republish and jump to the top. I couldn't even reliably select images in the collections, because the grid was always changing so quickly. Really frustrating! Nice work by the folks posting to this thread in diagnosing the problem. Adobe really needs to fix this republish bug ASAP.

OK, if anyone is in the same position, there is a way to repair the before state. Right-click the 1st 'import' history step, and select 'Copy history step settings to before.' That resets the before state to the original import. Of course, it's only one image at a time, but better than nothing.

Well I was quite happy about this workaround until I realized that writing/reading the metadata breaks the Develop module before/after functionality. Not so good.

Writing/reading the metadata apparently resets the develop module before state to when the metadata file was read into the catalog. Previous edit states still exist and can be accessed, but 'y' and'\' no longer show the original imported image.

Images in published collections jumping to Republish was driving me insane, but now I have 1000 images that I can't use the '/' and 'y' key to check before and after. I'm not sure I understand what the read/write workaround is doing, but is there a way to correct the metadata without breaking before/after? And is there a way to repair my metadata to restore correct before/after?