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

  • 17
  • Problem
  • Updated 7 months ago
  • Acknowledged
  • (Edited)
[Update from John R. Ellis:

At least some instances of this bug are caused by the new develop settings added by CC 2015.6 for the Guided Upright tool (2015.6 was released 6/8/2016). When 2015.6 or later first renders a photo at 1:1 zoom that had been imported by 2015.5 or earlier, it adds those develop settings before rendering. Then it compares those develop settings with the old, notices they are different, and incorrectly marks the photo to be republished.

Here's how to work around this instance of the problem: https://feedback.photoshop.com/photoshop_family/topics/modified-to-republish-problem?topic-reply-lis...

See here for a detailed recipe to reproduce the bug, along with an analysis of the problem and suggested fix: https://feedback.photoshop.com/photoshop_family/topics/modified-to-republish-problem?topic-reply-lis... ]
-----------------------------------------------------------------------------------------------------------------

Sometime photos in my published collections began to randomly mark themselves as modified to republish.   Photos I haven't touched in years, in galleries I haven't recently changed, all of a sudden appear under 'Modified Photos to Re-Publish.'   If I even scroll through a collection, dozens of the images begin to jump up to 'Modified Photos'. I can select the photos and send them back to 'Published' with 'Mark as Up-to-Date,' but then more immediately jump up to Modified.
Photo of Mauro Iannicelli

Mauro Iannicelli

  • 11 Posts
  • 0 Reply Likes
  • Frustrated

Posted 2 years ago

  • 17
Photo of Dan Hartford

Dan Hartford

  • 121 Posts
  • 50 Reply Likes
Yeah!   It's not obvious what LR decides is a "Change".  Obviously things like star ratings, titles, captions, exportable keywords or anything you do in the develop module cause it to go to Modified, but other more subtle activities can also do it. I don't know what else causes it to "jump" as you say, but it could be something as mundane as just opening the image in the Develop module or syncing with a mobile device or even publishing in an entirely different publish service.  I'm not saying that I know any of these 'changes' cause it to jump, but something does and it's not always clear what it was.  You may want to check what other plugin's you have active as sometimes work they do in the background could trigger LR to mark the image as having been changed.  One thing the gets me a lot is if I move a KW from one parent to another or fix a spelling error on a KW or any of its parents, or add/remove a synonym.

I've also seen situations where the act of publishing an images caused it to be marked as changed and have it pop right back to modified.  I think the issue here was the inability to turn off the cross transfer of comments.  So you have an image and publish it which sends it to the service.  Then LR asks the service for comments and the service replies with "none" or returns a new comment which in turn marks the image as modified when the comment is added to the metadata.  Circular logic.

It doesn't 100% solve the problem, but some 3rd party Publish Service plugin's, such as those from jfriedl, have a panel in Publish Service set up where you can check off the things you want to be considered a "Change" or un-check them so they won't be considered a change.  For example in his Facebook Publish Service plug-in you can check or un-check any of:  caption, copyright, creator info, GPS location, instructions, job identifier, exportable Keywords, label, provider, rating, source, title, image date.  when I switched from LR's Facebook plug in to JFriedl's and unchecked all but caption, Keywords and Title it reduced the problem you describe by over 90%.

Dan
Photo of Jeremy Wood

Jeremy Wood

  • 15 Posts
  • 1 Reply Like
This is at least the third post on this topic in the last couple of months. It clearly started with the 6.6.1 update. I'm only publishing to my HDD and pretty sure my hard drive / OS is not updating image metadata. Does anyone from Adobe read these forums?
Photo of Paul Dlugos

Paul Dlugos

  • 1 Post
  • 0 Reply Likes
I'm having the same problem-

 I'll go to a publish collection and while I'm looking at the published photos, they will suddenly appear as Modified Photos to Republish without any input from me.  This can happen one at a time or all at once.  I can mark them as Up to Date and clear them from republish status and then more will appear as Modified Photos to Republish
Photo of STEVEN SETTLEMYRE

STEVEN SETTLEMYRE

  • 1 Post
  • 0 Reply Likes
This reply was created from a merged topic originally titled Lightroom: Photos spuriously marked as "edited".

I am also having this issue. I created a series of new Smart Collections that simply write out JPEGs to folders on my hard drive. I "Publish" the Smart Collection using the Publish button, and randomly, after a photo is really published, it immediately appears in the "Modified Photos to Re-Publish" section. This is a huge inconvenience and an unacceptable bug that will kill many peoples' workflow.

Adobe Lightroom CC - 2015.6.1 build 1083169
Macbook Pro - Mac OSX El Capitan 10.11.6

Note: This conversation was created from a reply on: Lightroom: Photos spuriously marked as "edited".
Photo of Robert Duncanson

Robert Duncanson

  • 3 Posts
  • 1 Reply Like
This reply was created from a merged topic originally titled Lightroom: Photos spuriously marked as "edited".

I have experienced this for several months now.  I can reproduce the error at will.

If I browse my Flickr-collection, triggering preview-building, it WILL randomly kick photos into modified-to-re-publish. My collection contains nearly 3185 photos since 2007, therefore most of have had previews aged out. More to the point, I recently zapped all my previews (70Gb) due to disk swap. The random re-publish flagging then kicked into over-drive.

It only happens if I browse the Flickr collection (all markeed as up-to-date) in grid view. No selection necessary, just scrolling into a region of non-preview material will do the trick. Every thumbnail render does not trigger the flagging, only some. That is to say, it is not because previews do not exist, it is because they don't exist AND a sprinkling of voodoo.

Update: If I select all Flickr collection photos, then generate previews, the behavior occurs. For as long as preview build job takes to complete, i.e. in the background and without user interaction. 

In summary
- When previews are rendered...
- ...and some unknown condition is met (only some, not all, photos)...
- ... metadata change occurs, sufficient to nudge the SmartCollection logic

Auto-XMP is disabled. Catalog is consistency-checked on a regular basis.

Regards,
Robert

Lightroom version: CC 2015.6.1 [ 1083169 ]
License: Creative Cloud
Operating system: Mac OS 10
Version: 10.11 [6]
Application architecture: x64
Logical processor count: 8
Processor speed: 2.5 GHz
Built-in memory: 16,384.0 MB
Real memory available to Lightroom: 16,384.0 MB
Real memory used by Lightroom: 466.7 MB (2.8%)
Virtual memory used by Lightroom: 7,833.8 MB
Memory cache size: 3,767.8 MB
Maximum thread count used by Camera Raw: 8
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Displays: 1) 2880x1800, 2) 1680x1050

Graphics Processor Info:
AMD Radeon R9 M370X OpenGL Engine

Check OpenGL support: Passed
Vendor: ATI Technologies Inc.
Version: 4.1 ATI-1.42.15
Renderer: AMD Radeon R9 M370X OpenGL Engine
LanguageVersion: 4.10


Application folder: /Applications/Adobe Lightroom
Library Path: /Users/xy/Pictures/Cat2010_LR6.lrcat
Settings Folder: /Users/xy/Library/Application Support/Adobe/Lightroom

Installed Plugins:
1) Aperture/iPhoto Importer Plug-in
2) Canon Tether Plugin
3) DxO OpticsPro 10
4) DxO OpticsPro 10 Importer
5) Facebook
6) Flickr
7) HDR Efex Pro 2
8) Leica Tether Plugin
9) Nikon Tether Plugin

Config.lua flags: None

AudioDeviceIOBlockSize: 512
AudioDeviceName: Built-in Output
AudioDeviceNumberOfChannels: 2
AudioDeviceSampleRate: 44100
Build: LR5x102
CoreImage: true
GL_ACCUM_ALPHA_BITS: 0
GL_ACCUM_BLUE_BITS: 0
GL_ACCUM_GREEN_BITS: 0
GL_ACCUM_RED_BITS: 0
GL_ALPHA_BITS: 8
GL_BLUE_BITS: 8
GL_DEPTH_BITS: 24
GL_GREEN_BITS: 8
GL_MAX_3D_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS: 8
GL_MAX_VIEWPORT_DIMS: 16384,16384
GL_RED_BITS: 8
GL_RENDERER: AMD Radeon R9 M370X OpenGL Engine
GL_SHADING_LANGUAGE_VERSION: 1.20
GL_STENCIL_BITS: 8
GL_VENDOR: ATI Technologies Inc.
GL_VERSION: 2.1 ATI-1.42.15
OGLEnabled: true
GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod

Note: This conversation was created from a reply on: Lightroom: Photos spuriously marked as "edited".
Photo of Paige Miller

Paige Miller

  • 25 Posts
  • 4 Reply Likes
This reply was created from a merged topic originally titled Lightroom: Photos spuriously marked as "edited".

Last night, I came home from work, edited 3 photos, and then tried to create a smart collection where the criteria was "Edit Date" is Today. Much to my surprise, 91 photos were in the smart collection. Now I suppose it is remotely possible that I accidentally selected and edited these 91 non-contiguous files, but I consider this extremely unlikely. Also, it is remotely possible that Auto Sync was on when I edited these three photos, but that would show up in the history of all of these 91 photos, and there is nothing in history to indicate Auto Sync was on, or that new edits had happened since these were published via a Publish Service that left it's date-time stamp in the history.

This morning, I woke up, launched Lightroom, and created the smart collection anew. Since I had not used Lightroom overnight (I was sleeping), and Lightroom was closed overnight, I assumed that the smart collection with criterion "Edit Date" is Today would produce zero photos (as no photos had been edited Today, a few had been edited yesterday). The same 91 photos appeared in the Smart Collection.

Possible causes:
  1. Bug in Lightroom
  2. I was sleepwalking overnight and re-edited the same 91 photos, but don't remember doing it
  3. Space aliens
I think it's a bug.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3298 Posts
  • 825 Reply Likes
See Paige's original topic for an extended discussion of his symptoms: Lightroom: Photos spuriously marked as "edited" which are very similar to the symptoms reported in this topic.
Photo of esbehh

esbehh

  • 3 Posts
  • 0 Reply Likes
I have been experiencing the same problem for years with my Publish to Hard Drive folders.  I have over a dozen smart folders that only include photos that meet certain criteria:  the color of the photo must be Green (this indicates that its editing is final) and the capture date must be in a certain range (a particular calendar year).  This publishes all my final photos for each year into separate folders. I very rarely edit a photo i took years ago, but if i do i go to the smart folder to re-publish the photo.  Usually i find that other photos are in the "modified" category, too, and it's always baffled me but i've never worried about it too much because there were only a few thousand photos in each folder and typically only a few dozen mysteriously marked "modified" photos.

However, i recently changed my setup so i now have one smart folder that publishes ALL of my  "green" photos (30K+) to the hard drive on another PC on my network.  Now the problem is magnified and significant because the "modified" set of pictures is often thousands.  That means when i want to publish any of my new pictures (or ones i've re-edited) I have to publish literally thousands of pictures.  This takes a long time and consumes a lot of CPU, memory, and network bandwidth.

I found a post in an Adobe LR forum in  which a user thought that unchecking "remove person info" would fix this problem but it has not worked for me.

i'm happy to provide more details if it would help.
Photo of Thomas

Thomas

  • 1 Post
  • 0 Reply Likes
I have the same problem. After publishing a smart-collection the number of photos for republish is growing up continuous.
Usually it affects photos which are visible, when I scroll in film-strip or published photos.
It seems as if LR generate new thumbnails or previews.
That's very angry!
Photo of anonymess

anonymess

  • 26 Posts
  • 6 Reply Likes
The same thing happened to me today.  I am working on a batch of 150 to so photos; then suddenly 135 got marked as needing republishing.  They are showing the mysterious "metadata was edited externally" flag.  Now I have to update the links and proofread the whole InDesign book again.

I've checked the edit history on a sample of these and there are no edit steps on the photos since last published.  I have not changed the Publish service itself.  I have not changed any metadata either as far as I know (unless I hit something odd by accident).  No other application has written to these files - they are placed in InDesign but I am not using any other editing application.

Running Lightroom 2015.7, InDesign build 11.4.1.102, MacOS 10.12 on a high spec system with 32GB memory.
Photo of keirbriscoe

keirbriscoe

  • 2 Posts
  • 0 Reply Likes
I am having this problem only in the last couple of months. Simply opening an image in the Library module to view it causes it to be marked for republishing.

Im using a rMBP 13" with OSX 10.11.6
Lightroom 2015.7
Photo of Steven Settlemyre

Steven Settlemyre

  • 1 Post
  • 0 Reply Likes
I found this other issue (and solution) that seems to work for this issue as well.

https://feedback.photoshop.com/photoshop_family/topics/photos-publish-directly-to-modified-photos-to...
Photo of Matthew Weinel

Matthew Weinel

  • 4 Posts
  • 2 Reply Likes
I have the same problem. All collections mitgrate to republish without me changing anything. As others have said it seems to be when LR generates previews.  Steven Settlemyre's suggestion didn't work for me.

Windows 10, Lightroom CC 2015.7
Photo of Margie

Margie

  • 3 Posts
  • 1 Reply Like
I'm also having this problem, and I too have found that it seems to occur when previews are being generated, but not for every single image. Steven Settlemyre's solution didn't work for me either. Please fix it Adobe!
(Edited)
Photo of Margie

Margie

  • 3 Posts
  • 1 Reply Like
Further to my previous message: Today I turned comments off on SmugMug and that hasn't made any difference either.
Photo of Fredy Benavides

Fredy Benavides

  • 3 Posts
  • 2 Reply Likes
I have the same issue. I also noticed that when I zoom in a photo, LR marks that photo as modified.

Adobe please fix it. 
Photo of Robert Duncanson

Robert Duncanson

  • 3 Posts
  • 1 Reply Like
Good news. As of Lightroom CC 2015.7 (OSX Sierra 10.12.1), the problem appears completely cured. 

I have not observed a single "accidental" update flag for over a month. Additionally, reproducing the bug (in 2015.6/6.1 by browsing collection, a preview gen. triggers issue), no longer does anythign it should not. Excellent!

I don't suspect MacOS update (10.11 -> 10.12) had anything to do with it though, with both being applied on release (within days) I can not say for certain.


Lightroom version: CC 2015.7 [ 1090788 ]
License: Creative Cloud
Operating system: Mac OS 10
Version: 10.12 [1]
Application architecture: x64
Logical processor count: 8
Processor speed: 2.5 GHz
Built-in memory: 16,384.0 MB
Real memory available to Lightroom: 16,384.0 MB
Real memory used by Lightroom: 903.0 MB (5.5%)
Virtual memory used by Lightroom: 4,857.5 MB
Memory cache size: 985.1 MB
Maximum thread count used by Camera Raw: 8
Camera Raw SIMD optimization: SSE2,AVX,AVX2
Displays: 1) 2880x1800

Graphics Processor Info:
AMD Radeon R9 M370X OpenGL Engine

Check OpenGL support: Passed
Vendor: ATI Technologies Inc.
Version: 4.1 ATI-1.46.22
Renderer: AMD Radeon R9 M370X OpenGL Engine
LanguageVersion: 4.10


Application folder: /Applications/Adobe Lightroom
Library Path: /Users/xy/Pictures/Cat2010_LR6.lrcat
Settings Folder: /Users/xy/Library/Application Support/Adobe/Lightroom

Installed Plugins:
1) AdobeStock
2) Aperture/iPhoto Importer Plug-in
3) Canon Tether Plugin
4) DxO OpticsPro 10
5) DxO OpticsPro 10 Importer
6) Facebook
7) Flickr
8) HDR Efex Pro 2
9) Leica Tether Plugin
10) Nikon Tether Plugin

Config.lua flags: None

AudioDeviceIOBlockSize: 512
AudioDeviceName: Built-in Output
AudioDeviceNumberOfChannels: 2
AudioDeviceSampleRate: 44100
Build: LR5x102
CoreImage: true
GL_ACCUM_ALPHA_BITS: 0
GL_ACCUM_BLUE_BITS: 0
GL_ACCUM_GREEN_BITS: 0
GL_ACCUM_RED_BITS: 0
GL_ALPHA_BITS: 8
GL_BLUE_BITS: 8
GL_DEPTH_BITS: 24
GL_GREEN_BITS: 8
GL_MAX_3D_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_SIZE: 16384
GL_MAX_TEXTURE_UNITS: 8
GL_MAX_VIEWPORT_DIMS: 16384,16384
GL_RED_BITS: 8
GL_RENDERER: AMD Radeon R9 M370X OpenGL Engine
GL_SHADING_LANGUAGE_VERSION: 1.20
GL_STENCIL_BITS: 8
GL_VENDOR: ATI Technologies Inc.
GL_VERSION: 2.1 ATI-1.46.22
OGLEnabled: true
GL_EXTENSIONS: GL_ARB_color_buffer_float GL_ARB_depth_buffer_float GL_ARB_depth_clamp GL_ARB_depth_texture GL_ARB_draw_buffers GL_ARB_draw_elements_base_vertex GL_ARB_draw_instanced GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_framebuffer_object GL_ARB_framebuffer_sRGB GL_ARB_half_float_pixel GL_ARB_half_float_vertex GL_ARB_imaging GL_ARB_instanced_arrays GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_provoking_vertex GL_ARB_seamless_cube_map GL_ARB_shader_objects GL_ARB_shader_texture_lod GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_shadow_ambient GL_ARB_sync GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_compression_rgtc GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_texture_rg GL_ARB_transpose_matrix GL_ARB_vertex_array_bgra GL_ARB_vertex_blend GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_bindable_uniform GL_EXT_blend_color GL_EXT_blend_equation_separate GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_depth_bounds_test GL_EXT_draw_buffers2 GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_framebuffer_object GL_EXT_framebuffer_sRGB GL_EXT_geometry_shader4 GL_EXT_gpu_program_parameters GL_EXT_gpu_shader4 GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_float GL_EXT_provoking_vertex GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_stencil_wrap GL_EXT_texture_array GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_s3tc GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_integer GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_shared_exponent GL_EXT_texture_sRGB GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_EXT_transform_feedback GL_EXT_vertex_array_bgra GL_APPLE_aux_depth_stencil GL_APPLE_client_storage GL_APPLE_element_array GL_APPLE_fence GL_APPLE_float_pixels GL_APPLE_flush_buffer_range GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_packed_pixels GL_APPLE_pixel_buffer GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_specular_vector GL_APPLE_texture_range GL_APPLE_transform_hint GL_APPLE_vertex_array_object GL_APPLE_vertex_array_range GL_APPLE_vertex_point_size GL_APPLE_vertex_program_evaluators GL_APPLE_ycbcr_422 GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_ATI_texture_mirror_once GL_IBM_rasterpos_clip GL_NV_blend_square GL_NV_conditional_render GL_NV_depth_clamp GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_barrier GL_SGI_color_matrix GL_SGIS_generate_mipmap GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod
(Edited)
Photo of Matthew Weinel

Matthew Weinel

  • 4 Posts
  • 2 Reply Likes
2015.7 doesn't fix it for me.

Windows 10, Lightroom CC 2015.7
Photo of Martin Meßmer

Martin Meßmer

  • 11 Posts
  • 1 Reply Like
Same here: Windows 10 / Lr 6.7:
- Double click photo to get 1:1 Zoom and the photo becomes "Modified to Re-Publish"
- re-publish photo
- double-click the photo again: this time it stays "Published"

It seems that if you have a preview in cache, nothing happens, but if the preview has to be rendered, it will trigger the state change.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3298 Posts
  • 825 Reply Likes
If this reliably happens, it would be great to determine if particular metadata fields indicate the proximate cause of the problem.   Adobe hasn't acknowledged any interest in tracking this down yet, but if we can narrow the cause, it's more likely they might fix the bug.

1. Select a file that hasn't yet been zoomed.

2. Do Metadata > Save Metadata To File.

3. In Finder/File Explorer, save away a "before" copy of the file (and it's .xmp sidecar, if it's a raw).

4. Double-click to 1:1 Zoom to trigger the problem.

5. Do Metadata > Save Metadata To File.

6. In Finder/File Explorer, save away an "after" copy of the file (and it's .xmp sidecar).

7. Upload the before and after copies to Dropbox (or similar) and post the sharing link here.
Photo of Martin Meßmer

Martin Meßmer

  • 11 Posts
  • 1 Reply Like
Hi John,
excellent approach!

And in fact, there is a difference in the XMP data (just an excerpt ot the modified XMP section):

Before;
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c011 79.156380, 2014/05/21-23:38:37        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
xmlns:xmp="http://ns.adobe.com/xap/1.0/"
xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:lr="http://ns.adobe.com/lightroom/1.0/"
xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
xmlns:exifEX="http://cipa.jp/exif/1.0/"
aux:LensInfo="173/32 519/32 0/0 0/0"
aux:Lens="5.4-16.2 mm"
aux:ApproximateFocusDistance="29/100"
aux:FlashCompensation="0/1"
aux:Firmware="1.01"
xmp:ModifyDate="2006-08-20T12:54:16"
xmp:CreateDate="2006-08-20T12:54:16"
xmp:MetadataDate="2016-04-17T20:38:19+02:00"
photoshop:DateCreated="2006-08-20T12:54:16"
xmpMM:DocumentID="2E0940B7A84BFEC2CCAAE2CFDEED0A08"
xmpMM:OriginalDocumentID="2E0940B7A84BFEC2CCAAE2CFDEED0A08"
xmpMM:InstanceID="xmp.iid:51f5e818-c515-b543-8281-63f9afd52500"
dc:format="image/jpeg"
crs:RawFileName="2006_08_20_IMG_4509.JPG"
exifEX:PhotographicSensitivity="58"
exifEX:LensModel="5.4-16.2 mm">
<xmpMM:History>
<rdf:Seq>
<rdf:li
stEvt:action="saved"
stEvt:instanceID="xmp.iid:51f5e818-c515-b543-8281-63f9afd52500"
stEvt:when="2016-04-17T20:38:19+02:00"
stEvt:softwareAgent="Adobe Photoshop Lightroom 6.5 (Windows)"
stEvt:changed="/metadata"/>
</rdf:Seq>
</xmpMM:History>

After:
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c128 79.159124, 2016/03/18-14:01:55        ">
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
<rdf:Description rdf:about=""
xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
xmlns:xmp="http://ns.adobe.com/xap/1.0/"
xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/"
xmlns:stEvt="http://ns.adobe.com/xap/1.0/sType/ResourceEvent#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:lr="http://ns.adobe.com/lightroom/1.0/"
xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
xmlns:exifEX="http://cipa.jp/exif/1.0/"
aux:LensInfo="173/32 519/32 0/0 0/0"
aux:Lens="5.4-16.2 mm"
aux:ApproximateFocusDistance="29/100"
aux:FlashCompensation="0/1"
aux:Firmware="1.01"
xmp:ModifyDate="2006-08-20T12:54:16"
xmp:CreateDate="2006-08-20T12:54:16"
xmp:MetadataDate="2016-11-19T22:36:29+01:00"
photoshop:DateCreated="2006-08-20T12:54:16"
xmpMM:DocumentID="2E0940B7A84BFEC2CCAAE2CFDEED0A08"
xmpMM:OriginalDocumentID="2E0940B7A84BFEC2CCAAE2CFDEED0A08"
xmpMM:InstanceID="xmp.iid:ba87e843-bb02-4342-a649-cd168c2f9d84"
dc:format="image/jpeg"
crs:RawFileName="2006_08_20_IMG_4509.JPG"
exifEX:PhotographicSensitivity="58"
exifEX:LensModel="5.4-16.2 mm">
<xmpMM:History>
<rdf:Seq>
<rdf:li
stEvt:action="saved"
stEvt:instanceID="xmp.iid:ba87e843-bb02-4342-a649-cd168c2f9d84"
stEvt:when="2016-11-19T22:36:29+01:00"
stEvt:softwareAgent="Adobe Photoshop Lightroom 6.7 (Windows)"
stEvt:changed="/metadata"/>
</rdf:Seq>
</xmpMM:History>

If I get it right, Lr is filing a metadata change
      stEvt:changed="/metadata"/>
which will definitely trigger the re-publish event.

Martin

Edit: sorry for the bad layout of the code blocks, I'm adding a screenshot from WinMerge showing the differences, hope this renders better.

(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 3589 Posts
  • 928 Reply Likes
If you did Metadata > Save Metadata To File as described in my steps above, that would account for the changes -- LR will always update those fields whenever it updates the metadata in the file.  

Can you repeat this again, but this time, first set the option Catalog Settings > Metadata > Automatically Write Changes To XMP.  Then repeat the steps but omit Save Metadata To File, instead just waiting 60 seconds before grabbing a copy of the file after zooming (to give LR time to write the metadata changes back if they have changed).   

Also, it looks like these are JPEGs.  Can you upload the before and after JPEGs to Dropbox or similar, so I can put them under the microscope?  There are many more fields than those recorded in XMP.

So the steps would be:

1. Set the option Catalog Settings > Metadata > Automatically Write Changes To XMP.

2. Select a file that hasn't yet been zoomed.

4. In Finder/File Explorer, save away a "before" copy of the file.

5. Double-click to 1:1 Zoom to trigger the problem.

6. Wait 60 seconds, then in Finder/File Explorer, save away an "after" copy of the file (and it's .xmp sidecar).

7. Upload the before and after copies to Dropbox (or similar) and post the sharing link here.
Photo of Martin Meßmer

Martin Meßmer

  • 11 Posts
  • 1 Reply Like
John,

I'll do that in a minute, but here is another interesting observation:

When I re-publish the photo and zoom-in again (which now does not trigger the re-publish event), Lr again files an new  <xmpMM:History> of the same type.

So, it's may be not the 
stEvt:changed="/metadata" 
but the
stEvt:softwareAgent="Adobe Photoshop Lightroom 6.7 (Windows)"
which did change from Lr 6.5 to Lr 6.7 between the two previous events.
Photo of Martin Meßmer

Martin Meßmer

  • 11 Posts
  • 1 Reply Like
"Automatically Write Changes To XMP." was already set:

http://messmer-online.de/2009_10_30_DSC-HX1_DSC00955-Before.JPG

Zoom-In ( photo is to re-publish), waited 60 secs, closed Lr (just to be very sure Lr did write back any changes):

http://messmer-online.de/2009_10_30_DSC-HX1_DSC00955-After.JPG

but no changes in JPG file.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3292 Posts
  • 820 Reply Likes
So that suggests the problem is not with metadata, at least the metadata that is written back to the file. 
Photo of John R. Ellis

John R. Ellis, Champion

  • 3589 Posts
  • 928 Reply Likes
One more thing to try.  Download and install this plugin: https://dl.dropboxusercontent.com/u/21811200/showmetadata.1.1.zip (see here for directions on installing a similar plugin).

When you run it on a selected photo, it displays a window with all the catalog metadata that plugins can access, not all of which is written to the file by Save Metadata To File.

1. Select a photo, and do File > Plug-in Extras > Show.  Copy the displayed "before" metadata from the window.

2. Double-click to zoom and verify photo is marked for republish.

3. Do File >  Plug-in Extras > Show again and copy the displayed "after" metadata.

Post the before and after metadata here.
Photo of Martin Meßmer

Martin Meßmer

  • 11 Posts
  • 1 Reply Like
That's a cool tool!

Results:
http://messmer-online.de/Metadata-Before-After-Zoom.zip

Metadata Before and After differ a lot in the Delevop section. But if you sort the Develop section, you'll find that the only difference are the following new items in the 'After' version:

PerspectiveX = 0,
PerspectiveY = 0,
UprightCenterMode = 0,
UprightCenterNormX = 0.5,
UprightCenterNormY = 0.5,
UprightFocalLength35mm = 35,
UprightFocalMode = 0,
UprightFourSegmentsCount = 0,
UprightPreview = false,
UprightTransformCount = 6,
UprightVersion = 151388160,

I did not even enter the Develop mode!
(Edited)
Photo of John R. Ellis

John R. Ellis, Champion

  • 3589 Posts
  • 928 Reply Likes
Interesting, these are the only differences.  The Develop settings are for the Guided Upright tool, which was introduced in CC 2015.6 / 6.6.    Here's what may be happening:

1. You zoom-in on a photo last edited in CC 2015.5 / 6.5.   

2. LR decides it needs to render the photo, and as part of that, it adds the develop settings for Guided Upright (at their default values).

3. It compares the new develop settings with the old, sees that they're different, and marks the photo for republishing.  (Though publishing services can define which metadata fields should be considered when decided if a photo should be republished, I believe that changes to develop settings always trigger a republish.)

A potential fix is to make the comparison of old and new develop settings smarter, so that a nil-valued (missing) Guided Upright setting is considered the same as the default value, and thus "no change".

Which publish services have you observed with this problem?