P:Show me where the duplicates live when synchronizing a folder to pull in photos outside of catalog

[naestyoh]

CURRENT:

When importing (synchronizing), I can choose "Don't Import Suspected Duplicates". When I'm looking at a current folder inside Lr which has a subset of files contained found inside to folder i'm sychronizing (say 10 have been imported previoiusly to Lr out of 100 I can see in Finder), I can see the full 100 in the Lr grid view initially but Lr quickly removes all 100 and the import becomes 0. This is expected and means that 10 files are in the catalog plus the 90 other photos are currently somewhere else in the Lr catalog. Where? No idea. Lr doesn't allow me to search for these files. I have to go external and use Finder to search them out. 

WANT: 

I want Lr to show me where those 90 duplicate files are residing while working in the import dialog. Use the same grid layout to segment the photos by folder. Let me jump to those folders by clicking on the folder names. This could be a way to Move those photos from all of the folders they might live in to the folder I'm currently synchronizing. 

[goldstar46]

Take a look at the below URL:

The program Name is:  "Duplicate Cleaner Pro"

https://www.duplicatecleaner.com/

If you do use the above, it will have to be 'outside' of the LRC environment...

... AND, after any 'actions' and/or 'deletions' you need to "Resync" your "folders" to clean for deleted images.

The above program is 'granular' enough that you can compare 'Forder" against "Forlder" and make your decision on what to remove.

Let me know if this helps

Cheers

George Veazey

[naestyoh]

I'm using 2 other apps (Gemini 2 and Duplicate File Finder on Mac) that are similar to the windows app you linked. Neither of these apps nor others I've tried so far have been robust enough to trust. IE: I was comparing two folders with the exact same files yet the app doesn't see them as duplicates becuase the meta had been updated on one of the folders. "Last Opened" was different. This type of de-duplication can also wipe out Lr edits and all virtual copies created. 

[goldstar46]

Naesyoh...

I can assure you, that the mentioned program is much different...

The software I am talking about offers you the actual "Hash" ID of each and every file as it is compared... when it does the comparison and when it shows the 'duplicate file' it also shows you the duplicate 'hash' ID tag......

I have been using this software for about a year and... I would strongly encourage you to give this software a 'try' if you are serious about solving your problem.

I don't know how much more 'identical' you want than the actual 'Hash' tag of the file to make sure you have it 'right'??

Hope this helps

George Veazey

[naestyoh]

That's the issue: the hash becomes different because the development meta is stored in the file header for JPG, DNG, etc. If I import the dupe file at some point into an editor without even saving any edits (with auto sidecar xmp ON), the hash becomes different from the duplicate sitting on a source drive. 

md5 -q sean-hoyt-oculus-nyc-warp-2200px\ copy\ 1.jpg
ab733c46a95873d5beb198c380d2db7b
md5 -q sean-hoyt-oculus-nyc-warp-2200px\ copy\ 2.jpg
ab733c46a95873d5beb198c380d2db7b

/* made small exposure change in Lr */

md5 -q sean-hoyt-oculus-nyc-warp-2200px\ copy\ 2.jpg
2d33ebcec4704e75fbec741fea1b1b0a

So, if going off hash, a direct dupe would work but Lr adjustments would make seem like a different file on disk from the original. This speaks to the trust I was talking about. Some dupes would be found if imported but nothing was manually or automatically adjusted. But, many others won't be identified because AUTO (or anything) was applied during or after import of the primary or duplicate files.