Lightroom Publish "The parameter is incorrect (1)" Error in Image

ColdForest

Hello, I'm receiving a "The parameter is incorrect. (1)" error on an image I'm attempting to publish to a gallery (from LR 2015.7 w/Smugmug v3.0.9.0). The original gallery was created via the plugin and 298 of the original 299 images published fine. One of these continues to fail with the aforementioned error.

Here's (a portion of) the debug log for this operation/error:

09/24/2016 07:06:51 DEBUG Wait for render (_DSC1351.NEF)
09/24/2016 07:06:57 DEBUG Render complete: C:\Users\David\AppData\Local\Temp\34A92DDB-8AEE-4826-8CE5-C5DFE1D874B6\_DSC1351.jpg
09/24/2016 07:06:57 DEBUG SmCommon.callMethod - start
09/24/2016 07:06:57 DEBUG Timestamp Offset: 0
09/24/2016 07:06:57 DEBUG GET: https://api.smugmug.com/api/v2!authuser?_verbosity=1&_accept=application/json&oauth_version=1.0&oauth_signature=<snip>&_noredirect=true&_config=[]&oauth_token=<snip>oauth_signature_method=HMAC-SHA1&oauth_nonce=<snip>oauth_timestamp=1474726017&oauth_consumer_key=<snip>
09/24/2016 07:06:58 DEBUG HTTP Status: 200
09/24/2016 07:06:58 DEBUG SmCommon.callMethod - end
09/24/2016 07:06:58 DEBUG SmMedia.upload - start
09/24/2016 07:06:58 DEBUG Timestamp Offset: 0
09/24/2016 07:06:58 DEBUG Filesize: 6.76 MB
09/24/2016 07:06:58 DEBUG HTTP Status: none
09/24/2016 07:06:58 DEBUG nil
09/24/2016 07:06:58 DEBUG Upload Time: 1s (Timeout: 300s)
09/24/2016 07:06:58 DEBUG Upload Bandwidth: 651.13 mbps
09/24/2016 07:06:58 DEBUG {"errorCode":"unknown","name":"The parameter is incorrect.\r\n","nativeCode":87}
09/24/2016 07:06:58 DEBUG {"code":1000,"message":"The parameter is incorrect.\r\n","stat":"noresponse"}
09/24/2016 07:06:58 DEBUG SmMedia.upload - end
09/24/2016 07:06:58 DEBUG SmMediaDigest.sync - start
09/24/2016 07:06:58 DEBUG SmMediaDigest.sync - end
09/24/2016 07:06:58 DEBUG SmPublishService.processRenderedPhotos - end

Any ideas? Is this some kind of EXIF idiosyncrasy?

Thanks in advance!

ColdForest

Just wondering if this is maybe not the correct forum to post questions regarding the Lightroom SmugMug plug-in?

Ferguson

Depends on if one of the guys show up who might know, but if you have a repeatable problem on current plugin (and that looks current) I would send it off to help@smugmug.com, and they will open a ticket and definitely respond.

ColdForest

Will do, thx.

leftquark

Sorry for not replying sooner ColdForest. We've been bouncing some ideas back and forth with our contacts at Adobe to understand what this error is since we've never seen it before. Our Lightroom developer is still trying to investigate.

ColdForest

Thx. I'll standby here (my contact at SM support also appears to be latched on this effort).

devbobo

ColdForest,

This error being raised is a native Windows error rather than an error that LR is raising specifically.

If you google " The parameter is incorrect 87", you get a number of different reports mostly regarding hardware related issues.

This post suggests trying a CHKDSK.

I hope that helps.

Cheers,

David

ColdForest

Hi David,

I ran a chkdsk and this completed successfully - absolutely no errors.

I'm still not clear why this is a SM plugin error (even though this shows up as a native 87 (ERROR_INVALID_PARAMETER)) error. All other operations that I've tried on this file (including exporting it to disk) work fine. There must be something more specific that SM is trying to do here that's failing. What is the specific Windows API that's receiving the error (is this just a call to OpenFile()?)?

Thanks!

ColdForest

I also wanted to mention that other publishing services have no problem publishing this raw file (e.g., Jeffrey Friedl's PicasaWeb publisher). So I'm still not clear on why SM's publisher is having difficulty?

ColdForest

I'm still seeing this error (on this one image and only in my SM publishing service - and not other publishing services). This must be something related to the SM plug-in. Any ideas?
Thx.

ColdForest

Still seeing this...

leftquark

David's on holiday for the new year but I'll make sure to ask him if has any additional ideas when he's back!

ColdForest

Following up on this again. I'm still seeing this with version v3.1.2 of the plugin (from the debug log):
06/18/2017 15:51:56 DEBUG SmMedia.upload - start
06/18/2017 15:51:56 DEBUG Filesize: 8.18 MB
06/18/2017 15:51:56 DEBUG HTTP Status: none
06/18/2017 15:51:56 DEBUG nil
06/18/2017 15:51:56 DEBUG Upload Time: 1s (Timeout: 300s)
06/18/2017 15:51:56 DEBUG Upload Bandwidth: 3.99 gbps
06/18/2017 15:51:56 DEBUG {"errorCode":"unknown","name":"The parameter is incorrect.\r\n","nativeCode":87}
06/18/2017 15:51:56 DEBUG {"code":1000,"message":"The parameter is incorrect.\r\n","stat":"noresponse"}
06/18/2017 15:51:56 DEBUG SmMedia.upload - end

Can someone please help with what's going on here?

ColdForest

Hello, noone ever did get back to me on this and I'm still seeing this error (same characteristics - no other problems with this file and only SM publisher reporting the error). Is there really no way to move this forward so I can get this image published?
Regards,
-David

frisson

Hello ColdForest,

I came across your post. I have the same problem and I was wondering if you managed to resolve it. Like you, smugmug has been unresponsive and I doubt its really a hardware problem.

Thanks

leftquark

If you can follow the instructions to send us the log files, that would be super helpful! Feel free to email them to us at help@smugmug.com and our developer can take a look.

frisson

Thanks. In fact I uploaded my files on July 21 to SmugMug Help drop box and was responded to by David on July 24, who suggested it was a hardware error to which I replied July 27... and then nothing. It is not clear if anybody actually looked at the log file.

Here is the case reference. Let me know if the log file is no longer there.:
https://smugmug.kustomerapp.com/app/customers/593ed1b3970c3e0010900961/event/5b4a5606cb17eecd1f4eecef

leftquark

Thanks for the additional information @frisson. Because David is one of our developers, who is given the weekend to spend with his family, he hadn't had a chance to respond again. David did review the log file but the error is something caused on Adobe's end that we're unable to troubleshoot further. We've reached out to Adobe to see if they have any additional insights or can solve in a future Lightroom version. I'll respond here if we find anything from Adobe.

ColdForest

Hi frisson,

This is still open for me as well (still getting the same error and log information). As you've already seen no follow-up from SmugMug on this.

Regards

frisson

Thanks for letting me know. Like you I seem to have the problem only with the plugin. BTW,did you try uploading the picture directly through smugmug instead of using the plugin?

i guess I will contact adobe myself.Here is the last I received from the development team:

It's your prerogative to dismiss my assessment, but unfortunately, the error in question is being returned from a function in the Lightroom SDK. As a result, I have no additional insight into the issue than the error message that I am displaying to you in LR.

You could try submitting a help ticket directly to Adobe, but I believe that doing some self assessment of your hardware (no matter how old or new) may be the best approach. As a side note, when I first contacted Adobe about this error, they had never encountered it.

leftquark

I'll reach out to Adobe again and see if they have any additional insight. However, since it's an issue with one of their functions, the best we can do is push on them to fix it. Other Plugins may not experience this issue because they're not using the same methods we use and since our plugin is more powerful than most other plugins, we're doing some things in a way that working around this issue might remove some of those advanced features. If we get any news from Adobe, I'll post here.

ColdForest

@frisson No, I haven't tried this by uploading directly to SM, but I expect this wouldn work.

@leftquark As a computer scientist I'm quite frustrated how this request has lingered and why noone seems to understand the root cause for the error. Regardless of which API is in use (SM or Adobe) some developer must know more specifics regarding the underlying error. Bizarre.

leftquark

@ColdForest: Frustrating for sure. This is a case of an API function that is available and works 99% of the time. It's the only method to do a specific thing we're trying to do, so there's no alternate code that could be written to work around the issue. The error fails at the Adobe side, so the best we can do is alert them of the issue. But they have to do their own prioritization on bugs and since I'm sure Lightroom has many bugs and they're deeply working on a complete rewrite of Lightroom, my guess is that it just doesn't make it high enough on their prioritization scale. But we've done our best to reach out to them to push them to look deeper into fixing it!

frisson

I tried uploading one of my problem files directly from SmugMug's organizer. That worked, except it had not captured my LR edits. So I exported my photo (to capture the edits), reimported into LR and then tried to publish. And that worked! Perhaps that will give you some insight as to the problem. I think the association of this error with a hardware problem is unlikely. There must be something specific with the files themselves. It is wierd that so few people have an issue. I am frustrated by the fact that nobody seems to be looking at the files causing the problems.

Thoughts

Ferguson

If it's always the same file, is it a file you are willing to share? I can't speak for smugmug, but I'm sure others here (including myself) would be willing to import it and try publishing, as a way to see if it's very specifically that image, those edits, or something else.

Along those lines if you want to try, create a virtual copy of the image, reset it (i.e. clear all develop settings on the copy) and try publishing the copy. That would indicate potentially whether it is the image itself, or the edits to the image.

Along the same lines, on the copy, start changing metadata - titles, captions, keywords, etc and see if you can identify some aspect of the (changeable) metadata that causes it.

That the exported jpg can be published is not all that surprising, as a lot of things may change in that path versus directly publishing. While publishing renders a jpg, it might not render it the same way (different settings in your publish vs export run), it might remove or change metadata, filenames, etc.

Yes, one could argue you shouldn't have to work so hard to debug Adobe code, but welcome to Adobe world. If you can pin it does, e.g. if you find a specific character in a metadata field causes the issue, that's the kind of bug adobe may pay more attention to -- and more importantly you can avoid.

frisson

Yes, I am willing to share the file. I am new at this forum, though and do not see how to attach the file. Also if I share the file (its a jpeg) how do I transmit the LR edits?

Thanks, for your suggestions, which have been the most useful so far. Its put me on the right track. Creating and resetting the virtual copy did not work. However clearing out the metadata in the virtual copy that I inserted manually - essentially title and caption - worked... even without resetting the virtual copy.

So more investigation on my part, though what is wrong with the metadata is not obvious.

Ferguson

@frisson, the original log posting would seem to indicate the image was a NEF raw, not jpg?

But if it's specific to the metadata, the image may not be needed. If you were to move that metadata title and caption to another image, does it fail there? I.e. is it the image PLUS the metadata, or just the metadata that makes it fail? If it's the latter (and the metadata is not confidential), just post it. I'd be happy to try, probably others. If you need the image perhaps upload somewhere like google drive or microsoft one drive and share a link to it and post, or PM it.

frisson

No, all photos that failed were jpg's and all that succeeded were raw. Its even weirder than that.

I can post the metadata, but I do not think it would be much use.

Here is what I did:

• Created a virtual copy of the problem photo and published. It failed.
• Copy and past the caption and title into an arbitrary image from a problem photo and published. It succeeded.
• Created a virtual copy of the problem photo, removed caption and title and published. It succeeded.
• Copied the caption and title from the original problem photo back into the virtual copy that succeeded without any changes. It succeeded!
• Did this for several 'problem photos'. All succeeded.

ColdForest, you may want to try something similar.

Go figure!

Ferguson

Did you try clearing and then replacing the metadata in the original problem photo and see if that fixed it?

Any chance there are some invisible characters in the data (I realize I'm not quite sure how you could see those in LR, though it is probably possible if you have a slqlite manager to dump it, but that's not really easy unless you are a programming type.

frisson

I think you are on the right track about invisible characters..

• I removed the metadata from the original problem photo and copied and pasted the same data from the virtual copy that had succeeded and published. It failed.
• I removed the metadata from the problem photo and published. It succeeded.
• I then copied and pasted the metadata from the virtual copy into the original problem photo and published. It succeeded!

Note that in all these manipulations, I did not change the meta data. Just copied and pasted.

ColdForest

I've finally had a chance to play with the metadata aspect as well. Following @frisson's steps (I played with the 'caption' metadata field only) I see the same results. This is nice because I can now finally publish this lingering and problematic file !

I found nothing identifiable in the caption data that (visibly) suggested something odd. The metadata (as originally copied from the problematic image into Windows notepad) is as follows:
"Montserrat is a spectacularly beautiful Benedictine monk mountain retreat about one hour north west from Barcelona by train.

The history of Montserrat started in 880 when a small group of shepherd children saw a bright light descending from the sky in the Montserrat mountains. In the same moment the children heard angels singing and the music filled their hearts with a radiant joy."

I originally thought length might be a problem but, as with @frisson, simply copying this back and forth seemed to do the trick. Unfortunately, I now no longer have a copy of the problematic metadata. I could return to a previous copy (or just archive this) of the LR database (.lrcat file) but, honestly I'll likely just move on and remember this virtual copy/metadata copy/paste trick for whenever I might happen to see this again...

Thx to @frisson for warming up this issue and to @Ferguson for offering some suggestions.