Lightroom Upload Plugin Miss

DBR

I've been using the SmugMug Lighroom plugin to upload my images for quite some time, and have been quite happy with it. Thanks!

Recently, I have had several galleries which appear not to upload all modified images. For example, just now I tried to publish a gallery with 897 images, one of which was modified. After a while, the SmugMug plugin indicated that it was unable to upload the one remaining image.

I'm using Lightroom 5.7.1 under Windows 7 64-bit. I have version 2.2.5 of the SmugMug publishing plugin. I cleared the plugin log file, verified that it was set to log in verbose mode, published the gallery again, and observed the same problem - the one modified image was reported as failed to upload.

I am attaching the log file.

Thank you for your help with this.

David

DBR

I'm having another problem with the plugin, too. I set up SmugMug events, and use the plugin to sync pictures back to Lightroom, to mark my clients' favorites. In a way that appears similar to the publish problem, it is now not able to sync picture that it should.

I have a gallery in which there are 245 favorites. When sync-ing, I was able to match 244 of 245 images. The last did not find a match, although the original file is clearly still in lightroom. It appears that the plugin is using the date/time digitized as the timestamp for published JPGs, and is trying to match against the date/time original. This is unfortunate behavior. In LR, I can (and do) adjust the date/time digitized to correct for camera clock inaccuracy. That adjusted timestamp should be on my exported JPGs.

The matching process appears to be giving more weight to the timestamp than the filename. It is matching my image using the JPGs timestamp, derived from date/time original, against LR images using the date/time digitized. They don't match, and it doesn't find the original.

I remember some discussion of the multiple timestamps quite a while ago (a year or two, I think), and thought that this issue was resolved then. Was there a change recently?

Incidentally, I'm attaching a log file from matching in case that is useful.

Thank you,

David

DBR

Yet one more issue
I see that I can select what metadata changes result in marking an image for republishing. I have Capture Time marked, but when I updated the capture time on a large number (maybe 4-5000) images, it did not mark them for republishing.

DBR

I see that in version 2.0.9 the release notes mention:

fixed image sync issue where DateTimeDigitized was not being obtained correctly

I suspect that at this point, the plugin started using the date/time digitized for JPG publication instead of the more proper date/time original, which LR uses be default as its timestamp for exported or published JPG images.

Are old versions of the plugin available for download somewhere? Unfortunately, I recently cleaned up and removed my old copies.

Thanks,

David

leftquark

Hi David,
Thanks for looking into this and doing so much troubleshooting -- it really helps us when we go to look into the issue. Our Lightroom Developer just left for a family trip and will be out for a week or two. As soon as he gets back I'll have him look into this.

Our Lightroom Plugin is now auto-updates and even if you went back to an older version, the new one would get pushed to you.

devbobo

DBR wrote: »

I see that in version 2.0.9 the release notes mention:


I suspect that at this point, the plugin started using the date/time digitized for JPG publication instead of the more proper date/time original, which LR uses be default as its timestamp for exported or published JPG images.

Are old versions of the plugin available for download somewhere? Unfortunately, I recently cleaned up and removed my old copies.

Thanks,

David

This is an incorrect assumption, we always use DateTimeOriginal as the primary source if available. The bug that I fixed was an issue related to DateTimeDigitized from scanned images, which obviously have no DateTimeOriginal

devbobo

DBR wrote: »

I've been using the SmugMug Lighroom plugin to upload my images for quite some time, and have been quite happy with it. Thanks!

Recently, I have had several galleries which appear not to upload all modified images. For example, just now I tried to publish a gallery with 897 images, one of which was modified. After a while, the SmugMug plugin indicated that it was unable to upload the one remaining image.

I'm using Lightroom 5.7.1 under Windows 7 64-bit. I have version 2.2.5 of the SmugMug publishing plugin. I cleared the plugin log file, verified that it was set to log in verbose mode, published the gallery again, and observed the same problem - the one modified image was reported as failed to upload.

I am attaching the log file.

Thank you for your help with this.

David

G'day David

Looking at the log you provided, I can see a 404 returned from the API when it tried to update the image metadata on SmugMug. In this case, where the image has been deleted from SmugMug, the plugin *should* re-upload the image. I haven't tested that recently but it doesn't appear to be working.

To resolve this issue, you should just remove the photo from the collection and re-add it.

I'll look at the issue with republishing a deleted image when I get back from holidays.

Cheers,

David

devbobo

DBR wrote: »

I see that I can select what metadata changes result in marking an image for republishing. I have Capture Time marked, but when I updated the capture time on a large number (maybe 4-5000) images, it did not mark them for republishing.

This most probably a LR bug, the plugin tells LR which triggers should result in an image being republished, but it's LR's job to actually mark the image to be republished.

DBR

devbobo wrote: »

G'day David

Looking at the log you provided, I can see a 404 returned from the API when it tried to update the image metadata on SmugMug. In this case, where the image has been deleted from SmugMug, the plugin *should* re-upload the image. I haven't tested that recently but it doesn't appear to be working.

To resolve this issue, you should just remove the photo from the collection and re-add it.

I'll look at the issue with republishing a deleted image when I get back from holidays.

Cheers,

David

David,

Thank you for looking at this before your holiday! I had to publish after deleting and before re-adding, but that took care of it. Incidentally, I don't think that the images in question were ever actually deleted from SmugMug - I certainly did not delete them. I believe that it was a glitch during upload. Perhaps it was due to load. I had about 3-4 sets of collections uploading simultaneously.

Enjoy your holiday!

David

DBR

devbobo wrote: »

This is an incorrect assumption, we always use DateTimeOriginal as the primary source if available. The bug that I fixed was an issue related to DateTimeDigitized from scanned images, which obviously have no DateTimeOriginal

Thank you for correcting me. I see that all three EXIF timestamps are actually included in the JPG image metadata on SM. I downloaded an image and confirmed this.

Unfortunately, SM displays DateTimeDigitized, not DateTimeOriginal as *the* timestamp (when I click on info). Apparently, the SM/Lightroom plugin uses this timestamp, also, when attempting to match images. However, it uses the DateTimeOriginal timestamp on images in LR. As a result, if I have modified my DateTimeOriginal (correcting for an incorrect camera clock, for example) I cannot sync images - the timestamps do not match.

I believe that the right way to solve this is to get SM to use DateTimeOriginal as the image timestamp. How can I do this?

Or am I mistaken in my analysis of what's actually going on?

Thank you!

David

DBR

David - I believe that you were planning to be back after a week or two. Have you had a chance to look at this?

Thanks!

David

leftquark

DBR wrote: »

I believe that the right way to solve this is to get SM to use DateTimeOriginal as the image timestamp.

Just for clarification you mean using DateTimeOriginal only for matching purposes, correct? When we display date taken on the SM website we should definitely be using whatever time stamp the user wanted us to actually use (edited if it was).

David will be back next week and I can ask him about this.

Lille Ulven

leftquark from my point I would love it if DateTimeOriginal was used for matching and presenting - seriously if I was to present a photo from say last Christmas, who would care about when my last post processing was done? Of course if there is a chance to use either DateTimeOriginal or any other timestamp on smug mug giving me the choice of how to sort stuff - I would not mind it at all (And it would probably work better for the RSS feeds as well.)

One strange thing that I have seen - and from what I have seen should come from the plugin rather than LR - when synchronizing the photos in my LR gallery sometimes (I haven't been able to figure out a rule when this exactly has happened and when not - if I find it I'll let you know) my photo in LR gets the value from DateTime (last post-processed / transferred to smug mug?) written into DateTimeOriginal. This might be something that has been fixed in one of the newer versions, as I cannot tell right now when this happened to my photos the first / last time. But this seriously messes stuff up for me as the DateTimeOriginal should never be changed outside LR (preferably not even there) as I use it to identify my photos and use it for example as a part of my filename.
I'll keep my fingers crossed that one of the "newer" plugin versions already had a fix for this, but will have a closer look later today when I am to synchronize a couple of files again.

Have a great weekend

Lille Ulven

DBR

leftquark - the real problem with the plugin is that it appears to be mismatching timestamps. That is, it apears to be comparing DateTimeDigitized on SmugMug with DateTimeOriginal in Lightroom. As a result, synchronizing images doesn't work very well if I have modified DateTimeOriginal. I frequently modify DateTimeOriginal, since that's the timestamp that Adobe products (such as LightRoom) use as the timestamp for images. Actually, I'd prefer that the plugin try to match DateTimeDigitized and not bother with DateTimeOriginal, since modifying DateTimeOriginal is actually part of editing my images. I guess the ideal would be for the plugin to use DateTimeDigitized (both in LR and SM), and look at the others only if that doesn't match. Or if that doesn't work for others, maybe it could be configurable. I agree wiht Lille that the last editing time is completely irrelevant to me.

This has been broken at least since my original post on 7 April - nearly 4 weeks ago - and I've been patiently waiting for David to return from his one or two week vacation. I have imminent deadlines, and am having to manually sync hundreds of images because of this. When you say next week, do you mean the beginning of the work week? Or do you mean another week? If the latter, I'm not happy with the original week turning into more than 3.

I recognize that people are busy, and that's why I haven't pushed this over the past couple of weeks. What needs to happen for this to move up in the priority queue?

Thanks,

David

leftquark

David is back and I'll bring this up with him. His first priority will be to update the Publish Plugin to fix the issues caused by Lightroom CC and I'll ask him about this after.

I often update the Date/Time taken of my photos, for example, if I accidently had the wrong time-zone set, and would expect LR/SM to sync properly regardless.

Lille Ulven

leftquark if you are updating your Date Time field via LR in what they so nicely call "Edit Capture Time" the field that actually is updated is "Date Time Original". "Date Time Digitized" or "Date Time" are not touched by this. "Date Time Digitized" actually reflects what ever time you had on your camera, while "Date Time" would be the last change date of the file on your hard disk (which remains untouched by the usual LR Development process).
So yes, DBR has a point saying that "Date Time Digitized" should be the one used for comparison between LR and SM, since you cannot change it in LR (yea, you can write a script to change that field too...), while using "Date Time" always comes with a mess-up risk.

Thanks for taking this up with David, leftquark - I am sure there will soon be a fix which makes all of us very happy.

DBR

Looking forward to a solution!