Lightroom: Multiple image move operation bug

Ben, I've had this happen at least 50 times during the 3.x cycle, moving images from folder-to-folder. And, yes, the image left behind moves on the second try every time. It seems to me that it requires a lot of images (perhaps 50 to 100 at least).

Not sayin' it doesn't happen. Just sayin' it doesn't happen for me. :-) So I'm trying to get some more info. Are your moves between drives, or on the same drive? Network drive or local drive? Any particular file type or size? Do you have the "Automatically write changes into XMP" preference turned on? Anything distinguishing you can recall about the times it succeeds vs. the times it fails?

It happens for me not at all. It's happened for you 50 times in the last year-plus, and requires moves of at least 50-100 photos. It happens to Glenn 75% of the time, with moves of only 10 photos. Clearly there's some variability here, so any additional info you can think of that might be relevant would help.

Thanks,
Ben

Same drive, local drives, all file types, no auto-write, XP and Win 7 64-bit, move by drag or by context menu.

@Ben:
Always moving between the same drive. I tend to shoot several hundred panoramas, with a black frame in-between for fast sorting. Afterwards I manually create folders (because LR ignores importing empty ones) e.g. pan01, pan02, and so on. Then I proceed to move the 8-20 images between black frames into the subsequent folders.

After I dismiss the error dialog, it works fine. That's what makes this so weird, it can't move the _highlighted_ image (of the batch) right this moment (locked by LR?) but immediately after I click the the away I can move it without a hitch. It seems to happen more often when i highlight the first image in the batch and then do the move.

btw i've tried this on an OCZ SSD, USB 3.0 (~80-100 MB/s), USB 2.0 (~20 MB/s) internal SATA II drives in single and RAID 0/1/0+1/1+0/5 (60-180 MB/s) configurations.

@Lee: only 50? I just had it happen around 50 times out of 75 attempts :( it's something i deal with on a weekly, if not daily basis.

I think the file is still being accessed by some other LR thread that can't easily be told to stop mid-access, like computing a preview or comparing metadata or whatever, and if you let it sit a little longer, it'll work more often, and the faster the computer/hard-drive the sooner it's finished, too.

LR has to move the file, any XMP sidecar and possibly the preview so there may be more files and time involved that what would seem obvious. It would be nice if LR would retry the move of any failed files, again, at the end.

I've thought the same, except speed of my drives hasn't seemed to matter at all. Also I don't shoot previews anymore, which has definitely helped speed things up a bit in general.

+1 to this: "It would be nice if LR would retry the move of any failed files, again, at the end".

Someone else has complained that their image's file-modifacation date gets updated to the current time whenever they click onto an image and have auto-XMP-writing turned on, and this cause Time-Machine to make a new backup copy even though nothing substantive was changed.

I wouldn't be surprised if LR opens the current file in read-write mode in case it needs to update the metadata (perhaps in the XMP file not the main RAW so the file i/o is not a factor) and then goes and checks the database version of the metadata before deciding not to do anything, but for the duration of the checking, the file can't be moved, anywhere. I have this problem when I move whole folder trees at the end of every month, and purposely put LR in Loup view and hide the thumbnail bar or make the thumbnails large so there are fewer, so a minimal number of files are being looked at and I just wait until the Loading... has stopped on the preview and there are no little dots on any thumbnails before trying to move the folders, but I'm dragging folders at the left, not individual images so I don't have to have grid-view or a row of thumbnails selected.

I share your speculation and experiences!

Moving folders is a whole other bowl of fruit for me that I won't get into. But similarly, to help alleviate slow moving of images (30+), I usually click on some other folder as fast as possible and watch the Moving Images status bar change from 10sec ETA to being complete. If grid view has to shuffle thumbnails as images are moved to/from the folder you're viewing, you might as well go take a coffee break.

Oddly enough, I can't say I've seen this behavior on OS X boxes.

Thanks for this, but the problem still exists in LR4. See my suggestions below.

And in LR 5... Surprisingly, after 2 years :)

I think you may have meant to say "3.6"

I don't expect it to be fixed in 3.6. The bug is still at Open/To Fix in our bug database.

-Ben

I had 3.6 until I re-ordered my sentence and now I can't edit the post. Thanks for correcting things.

I have only had LR for a week so am still settling in. Shall stick with 3.5 for the moment. Thanks for the update Ben

3.6 doesn't help, nevermind that it also adds all sorts of annoying quirks. After a couple weeks of frustration I went back to 3.5.

Why can't the move thread just note the error, and retry automatically once or twice with a small (e.g. 250ms) delay between? Even less work and no need for an extra dialog.

Also fine, but I don't think the problem is that we don't know how to fix it :-)

Thanks. The engineer is aware of the issue and bug is still active. (there's a recent comment in the bug report) It just hasn't risen up to the top of the priority list. I added a comment to the bug report as well pointing to this thread.

Please, the issue has been reported 9 months ago. It's very annoying and it's easy to fix.

This is typical "low hanging fruit", I would say.