# LR Transporter question - unique identifications



## Linwood Ferguson (Mar 12, 2016)

I was thinking of using this program to mass change some fields.

I've never paid attention much to file names since I have files in folders, and so I might have duplicate file names normally. 

In addition, the file name of a virtual copy is the same as the original.

When using LR Transporter for input, it APPEARS that the closest to a unique identifier you can use is file name, not including path.  At least that is what appears to be true?

And the documentation says if an import matches multiple files, all get updated.  So if you have two files with same names (say you just let the camera names flow in and they wrapped around, but were in different folders), it APPEARS it will update both.

Am I missing something?   How do you make sure you update only the same file on import that you got data from on export?


----------



## Victoria Bampton (Mar 12, 2016)

How about using the capture date/time instead?


----------



## Linwood Ferguson (Mar 12, 2016)

Victoria Bampton said:


> How about using the capture date/time instead?


The problem for me would be bursts.  There's a separate Subsecond field that would distinguish, but the program does not use that.   And I really don't want to give that up, as for sports it represents a sequence, like a dunk shot, that you want to keep in order.

I did a bit of SQL to see if I have duplicate file names, and I have a LOT of them from older times (code below if anyone ever needs it).

I guess I'm surprised no one ever found this to be a challenge for the program.  A fundamental idea for a database is a primary key, to be able to uniquely identify what you want updated.  I like that John Beardsworth's Listview will use UUID (an internal Guid), but it won't update the IPTC fields I need.


```
select filename, ar.absolutePath || afld.pathFromRoot || alf.idx_filename
from
(
   Select alf.idx_filename as filename, count(*) as cnt
   from Adobe_images ai
   inner join AgLibraryFile alf on alf.id_local=ai.rootFile
   where ai.masterImage is null
   group by alf.idx_filename
   having count(*)>1
) as f
inner join AgLibraryFile alf on alf.idx_filename=f.filename
inner join AgLibraryFolder afld on afld.id_local=alf.folder
inner join AgLibraryRootFolder ar on ar.id_local=afld.rootFolder
order by 1
```

Postscript: edited to reflect I confirmed it does not use subsecond portion of the field.


----------



## Linwood Ferguson (Mar 13, 2016)

Actually I looked more carefully -- the only fields that can be used to match are: 

Filename (this does not include path)
Filename without extension
Copyname
Title
Caption
Location
Job Identifier

So Capture Date/time is not an option.

Now today I think filename would be unique for me for what I am importing now, as I append a sequence number, but I've got years and thousands of images that were just the camera filename, which wraps (not to mention four different cameras involved).


----------



## Victoria Bampton (Mar 13, 2016)

How about renaming the existing files based on capture date/time, then even the burst ones would gain a -2.


----------



## Linwood Ferguson (Mar 13, 2016)

Victoria Bampton said:


> How about renaming the existing files based on capture date/time, then even the burst ones would gain a -2.



Well, yes, that's a possibility but not a happy one.  I use off-site backup in the cloud, two of them actually, and if I rename all the files I'll spend two weeks uploading.  But I think I could also do it only for duplicates.  Not sure quite how, but I can easily list the duplicates.

But all that said, I think (there's another thread going) that I do not need Transporter to actually import, as I think LR is fixing it dynamically.  See here.  LR seems to reset the field I needed to import.   I can use the LR Transporter export to find all the errors (just export all, then in a spreadsheet check if the times match close enough). 

But... maybe... if the author runs across this, they might consider adding a unique key, like the UUID or just the internal image number, so what you get out can go back in unambiguously.


----------



## mdolnik (Sep 13, 2016)

Has anyone found a solution to this?

I've tried (a few times over the last few years) to contact the Transporter plugin's author via email and haven't gotten a response.

This plugin is so close to being a very robust tool for lightroom (that and the keyword heirarchy problem, but that's another issue) but the fact that there is no way to isolate to a specific image just has this solution fall flat on its face.

I'm pretty sure most people who use lightroom will have duplicate filenames located in different folders, and renaming all photos to be unique would be a huge hassle.

Does anyone know how to contact the author besides the email on his webpage?


----------



## taylorfct (Sep 28, 2016)

I have a strong need for access to an unique identifier also, such as a UUID.  Likewise, I have tried without success to contact the author of LR Transporter also with no success.  Is this product even supported any longer?


----------



## Linwood Ferguson (Sep 28, 2016)

FWIW I never found a workaround with this tool.  I wish the open source donation model had taken effect for plugins, as it has in many areas - then the source would still be around for others to pick up and change.


----------



## mdolnik (Sep 28, 2016)

I did manage to find one open-source plugin *(That I haven't tested at all yet)* that says it can import keywords from a "csv" file

GitHub - tkampp/lr-keyword-importer: Keyword Importer Plugin for Adobe Lightroom

It hasn't been touched in 4 years, and oddly the "CSV" data is separated by a semi-colon

Also I have no idea how it handles keyword hierarchy (which LR Transporter doesn't do unless you import the full hierarchy)

I was thinking of forking the project at some point, to have an alternative to the LR Transporter issue, but I don't have much time to spend working on this yet.

But this might point some people in the right direction.



Ferguson said:


> I wish the open source donation model had taken effect for plugins


I agree, for giving away the plugin for any price, he should consider open-sourcing it if he no longer has time to support it.


----------

