Skip to main content
Inspiring
January 6, 2019

P: Importing photos - different files merged

  • January 6, 2019
  • 18 replies
  • 529 views

Importing a file, renaming it in Lightroom, then importing any other file with the same name generates incorrect records and does not import subsequent files. This is happening when scanning to a folder with autogenerated names, then using LR to import the files and rename.

1) Scan some slides to a folder named e.g. YYYY-MM-DD-sequence.TIF
2) Import into Lightroom (synchronise folder)
2) Rename or move those files elsewhere using Lightroom
3) Scan more files which are again auto-named, with the sequence restarting at 1 because the first ones are no longer there
4) Import the new files (synchronise folder)

Actual: LR notices the new files but creates duplicate records for the first set of images, even if they have been moved to a different folder and renamed. Removing one of the duplicate records actually removes both records, requiring a second "sync folder" to re-import correctly.

Expected: LR creates new records for the new files in the correct folder.

This topic has been closed for replies.

18 replies

Bob Somrak
Legend
January 9, 2019
I could see where a workflow as follows would/should be the same as the OP's scanning scenario and is probably a common workflow for some.  If it created problems I would think it would have shown up more often.

Have camera set to restart file numbering
Reformat camera card
Copy files to folder A
Sync folder A
Rename files
Reformat camera card
Copy files to folder A 
Sync folder A

  

 I would try this but I have NO interest in setting my camera to restart numbering as it might mess up my numbering system in the long run.  I'll let Adobe do this. : )
M4 Pro Mac Mini. 48GB
Inspiring
January 9, 2019
It's really not an uncommon workflow if a camera is set to restart file numbering on each memory card insert.  I know that's an option on my Canon's.  Not sure about others.
Bob Somrak
Legend
January 9, 2019
I haven't tried with a restart but now that Rikk Flohr acknowledged the bug it is in Adobe's hands.  Rikk is great at staying on top of of bugs he has duplicated and acknowledged.
M4 Pro Mac Mini. 48GB
Inspiring
January 9, 2019
Hey Robert, can you confirm whether it works properly for you if you restart Lr between imports?

Seems like it must or everyone who had their cameras set to restart file numbering each time a card is replaced would be running into this frequently and squawking about it.
Rikk Flohr_Photography
Community Manager
January 9, 2019
I can repeat this and have logged it with the team. As Bob says, a very obscure bug with a workflow that is uncommon. 
Rikk Flohr: Adobe Photography Org
Bob Somrak
Legend
January 9, 2019
As an added note, I have seen a couple other threads in the past concerning this issue of "phantom" thumbnails.  Here is one thread here:

https://forums.adobe.com/message/10503511#10503511
M4 Pro Mac Mini. 48GB
Bob Somrak
Legend
January 9, 2019
I am able to also consistently replicate this bug in Lr 8.1 and MacOS 10.13.6.   

This is a very obscure bug but is easily replicated so Adobe should be able to fix it.  Hopefully they will start fixing some of these easily reproducible ones, although history shows otherwise.

If I delete one they are both deleted.
I I select the pair and say "delete from disk" I get the following error which is probably expected.

M4 Pro Mac Mini. 48GB
Inspiring
January 9, 2019
I'm able to consistently replicate this behavior in Lightroom Classic CC 8.1 on Win10, if I do all the steps without ever closing Lr.  If I restart Lr between imports, it works normally, treating the images as different/separate entities.

Try restarting Lr before your second import (step 4) and see if you get the same results.

Also, does your scanning software have the ability to add the time to your auto-naming template?  If so, you could drop the sequence number and go with YYYY-MM-DD-HHMMSS.TIF.  Assuming you're not scanning more than one image per second, that should work around this issue pretty easily too.