I have multiple external USB drives. I will use only one USB drive at a time. When I connect it to my Win PC it will be mapped to drive P: - no matter which drive I connect.
In LR I would create a catalog file under P:\lightroom\lightroom.cat
This way all the editing information and thumbnails would reside on the same hard drive as the photos to which they relate.
When I want to work on photos from a different drive I quit LR, disconnect the first drive, connect the second (which picks up the same P: letter and has its catalog in the same P:\lightroom\ folder), start LR and it finds the catalog and loads up and knows all about the images on that next drive.
When I read about PhotoLab I learn it uses “sidecar” files. I’m told these contain the editing information and are stored in the same folder as where the photo resides. However when I enquire about the app generating thumbnails for its own use, I’m told these are stored in the app’s own cache - which will be on my internal hard disk, not the attached USB drive.
For this reason, if I follow my existing workflow, imagine for a moment two drives both have a file with same name and path; for example: P:\photos\folder_1\photo.nef
Will PhotoLab get confused when I move to my second USB drive - because it thinks it already has thumbnails in its cache for a photo at that path?
I’ve now set the “database” folder for the cache so that it resides on the external drive. Will see how I go when I switch drives at some point.
I haven’t yet searched for where to specify that sidecar files should be used - I was surprised to read that you can disable them - but browsing my photo folder I see that one .dop file exists (for the photo that I’ve started to edit).
@oatleyphotography With respect to the images DxPL does not, repeat does not use the drive letter for its means of identification. This has caused problems for users in the past but may or may not be of use to you!
DxPL uses the UUID of the disk in the case of both fixed and USB drives and the drive letter for Network drives.
So I looked at 2 local drives, F:\ (HDD), N:(NVME) and D:\ (a USB3 drive) and X:\ and Y:\ (both on a NAS drive) and we get
If I added another USB3 drive even with an identical layout and with the same drive letter, it would be treated as a separate drive and all the entries would be held apart from the previous USB drive.
The only way to “fool” the system is to allocate identical UUIDs to two drives, but Windows won’t allow those on the machine at the same time. The other way is to hack the database table.
So your data is fine as for the database and cache, both could be located on the USB3 drive and provided they are given the same drive letter then I believe that DxPL will simply use the files presented, but while I am sure about the use of the UUID for images I have not tested your given scenario.
PS:_ My tests in the past have included two identical copies on two USB3 drives (with unique UUIDs, of course) and everything is fine, the UUIDs are used to identify the disks regardless of the assigned drive letter.
Due to the UUID of volumes being used, PL should be okay with any number of external drives as long as the catalog/database files are kept on said drives.
If the catalog/database is kept on the computer and the different external drives contain folders and files with the same names, search will find all files, but the preview will contain frames with a question mark instead of a preview. This will mask any situation that can arise if files are moved or renamed while PL is not running.
If you don’t plan to use Projects (the ability to create logical groupings of images) and you don’t care about the ability to search images in the database by Keyword(s) … then you can delete the database - and rely only on the sidecar/.dop files associated with each source image to retain and apply corrections to the image;
I work this way by running PL via a wrapper that deletes the database (and the cache) before invoking each new PL session.
PL will then recreate a new database just for the current session (before it’s again deleted the next time that PL is run).
Provided one does not need projects and keyword searching, this works very well.
