SmugMug Plugin - "Export Operations Were Not Performed " - no other info provided?

[Three10]

After updating my SmugMug plugin to the latest version, I am having an issue with syncing/exporting via the plugin. I contacted SmugMug to see if they had any idea what the error meant. They said it was a Lightroom issue, while Adobe support chat suggested it was an issue with the Plugin that SmugMug was responsible for. So I'm hoping that someone in the community can help.

Here is a screenshot of the error:

This same error has been seen in multiple different machines at my company. This issue did not seem to occur before the SmugMug plugin was updated to 3.3.8.0. This app is running on Lightroom Classic 12.1 on different macOS machines - two iMacs, a MacBook Pro, a Mac Studio, etc. All them of them seem to fail with one or two photos that are unable to be exported/synced. They all seem to locate the photo in the /var/folders/ location and do not seem to be referencing the actual files, which are located on the machines regular hard drives ( Machintosh HD/users/ etc).

Any ideas on why this is happening? Any ideas to tell SmugMug on their plugin code?

[johnrellis]

You could try this third-party Smugmug plugin:

http://regex.info/blog/lightroom-goodies/smugmug/publish 

The author's export/publishing plugins are generally much better maintained than Adobe's.  

[Conrad C]

I use the Smugmug plug-in regularly and haven’t run into this, and mine is on version 3.8.8.0. Your post said you’re on 3.3.8.0, but should we assume that’s just a typo and your Macs are actually on 3.8.8.0?

I’m not technical enough to really debug this, but I notice that the file listed is a .CR3, and the file at the end of the /var path is a .jpg version of the same file. I believe /var is commonly used for temporary files, so it appears that the plug-in exports the .jpg versions to that folder, uploads those .jpg versions to Smugmug, and then after the upload is complete that entire folder appears to be deleted (when I try it). And to me that sounds like a normal use of /var . But the error might be caused by a glitch around that time when the .jpg is exported and then uploaded. Can’t guess any further than that.

I also notice the "(1)" at the end of the path, I kind of wonder if that means there were two copies exported from the same filename, like when a raw file and a virtual copy of it were exported at the same time. That should not normally cause a problem because Lightroom Classic should rename one to make it unique (I just tried that and there was no error), but I’m only bringing it up in case it leads to a clue, like when the error happens are any of the error images virtual copies?

Are all of the images with the error the same type, or do they vary at all? For example, are they all .CR3? If so, are they all the same type of .CR3, or were some shot as for example Canon C-RAW/M-RAW/S-RAW .CR3?

When I tested, I found the temp folder in /var , and none of the .jpg files in there end in (1). The uploaded duplicate got a "-2" appended to the end of its filename.

One way to troubleshoot would be to watch what is happening in that folder during export, and see how it fills up and empties. For me, the sequence is: When Publish is clicked, after a delay a new temporary folder is created inside /var.../T/ and if I can identify that folder while the export is still happening, I can see it start filling up with .jpg files of the photos in the publish collection. After upload is complete, the entire folder is automatically deleted. Publishing again creates a new temporary folder in the same location, but with a different folder name.

It looks like for both you and me, the folder name of the .jpg export cache is what follows after the /T/ (which is truncated in the screen shot). Because the /var folder is hidden, one way to get there in the Finder is by choosing Go > Go to Folder and entering the path; I used utility software that makes hidden folders visible. But again, from what I see the actual temporary folder being used under /T/ will probably change the next time you publish.