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.
@oatleyphotography to summarise what I said and @platypus emphasised and @John-M made the point that the database may be expendable, which is his and other users way of working, we have
DxPL recognises drives by the UUID not by the drive letter.
I believe that DxPL locates the database and cache by the drive letter, which can be defined by the user on Windows PCs. Hence it should be possible to locate both on the same drive and that could be the drive that also contains a collection (related or unrelated) of images. How easy it is to make that work in practice is still untested by me and it requires the user to be able to control the drive letter assigned to the drive otherwise the database will not be found and will default to an empty database in the default location. But one database can serve as many drives as required so that specific need may well be redundant.
Some (possibly many) users treat the database and cache as expendable and start with a new one of each for every edit session etc. or leave the cache intact and delete the database, relying on the DOP sidecar to maintain the image edit data. Some recent timings I did seem to indicate that on the latest release having the cache retained between sessions may be more of a liability than an asset but that might just be me and my testing rather than a reality!?
The database contains the wherewithal for maintaining âProjectsâ and the data for searching, both keywords and other metadata and âProjectsâ cannot be reconstructed from data in the DOP sidecar. âProjectsâ are held in the database on Windows PCs but âProjectsâ and âAdvanced Historyâ are held in the database on the Mac. The âAdvanced Historyâ on DxPL(Win) only lasts for a session. i.e. it is lost as soon as DxPL(Win} is terminated. Lose or destroy the database and all âProjectsâ data is gone, the search data can be reconstructed by re-discovering or re-indexing directories but âProjectsâ data is not recoverable.
When KeithRJ wrote âYou can specify in preferences where to store your cache filesâ - I assumed he meant PLâs âdatabaseâ (and not sidecar files).
I searched preferences and found indeed that I could specify for the âdatabaseâ to be located on the external USB drive:
Edit menu > Preferences⌠> General tab > DxO PhotoLab database > Location (requires restart)
When I first came here it was saving the database to the C: drive. I changed this to:
P:\photolab\database
After a restart I edited a photo - and have edited several since. That folder now contains:
When Iâm done with the photos on this drive I will shut down PL, disconnect the drive, connect another drive - which will also be assigned the drive letter P: and set up the same folder path. Restart PL and check that it knows the database is to be stored at the same location ⌠indeed, I expect the preferences already specify that.
John-M noted two features: using projects (logical groupings of images) and keywords ⌠I generally wonât use either of those. I organise my photos by folder on disk already and my systemâs worked for me since the 1990s. Given I shot 2,200 photos on my recent trip to Kruger NP ⌠on Day 1 of a 19 day trip ⌠I donât really care to go adding keywords to my photos either.
Keeping the database helps you take a (power off) break without losing any previous effort. Keeping several instances helps to prevent issues with duplicate folder and file names - issues inflicted to the human in front of the screen.
It makes sense to me that any PL metadata about the edits I make should be stored on the same external disk as the photos to which those edits apply. Say you have 10 external drives. Why should the editing information for anywhere from 10TB to 50TB of photos all be stored in a single database on my C: drive? Why wouldnât I want that info tied to the relevant drive where the photos are?
Other benefits - not that I need to do this - would be that I can grab any one of those drives and plug it into any PC thatâs running PL8 and just fire it up. The image edits are not tied to the individual PC on which they were made (unless PL has done that as some kind of licensing or security requirement).
I have been trying to use a single USB drive with two PCâs, and it has been a bit of a nuisance, because while the database may remain constant and intact, almost every other customization gets stored somewhere on C:. Presets, tone curves, ICC profiles, LUTâs, etc. So if you want to do this, some time needs to be invested in making sure your customizations are consistent between PCâs. I think I have decided itâs not worth the hassle for now.
Checked the situation on Mac (and there is no UI to set locations) and all the settings files I looked at only referenced the location of the database. All other locations are either hardwired or the settings are stowed or hidden somewhere else.
Deleting the database at the start of each new session does not alter/change/compromise that opportunity ⌠PL creates a new database (when it discovers that none exists), which is used for the duration of the new session.
Iâve been working with PL this way for a long time now - and thereâs no problem whatsoever (since I have no need for Projects or searching via Keywords).
Absolutely and definitely !! ⌠but, you donât need the database to achieve that.
Youâve said that you have no need for projects or keyword-searching - therefore, you have no real need to use PLâs database (between sessions) ⌠especially in your case where youâre continually switching in/out different P: drives.
Iâm suggesting that youâll find it much simpler to rely only on sidecar/.dop files, which should accompany their associated source-files (eg. RAWs) on each of your removable drives.
Exactly ! ⌠but, you donât need the database to achieve that.
All your correction data for each source-file is stored in its associated sidecar/.dop file ⌠you donât need the complication of maintaining a separate instance of the database on each separate removable drive ⌠In fact, I reckon thatâs a recipe for eventual regret !
âAppDataâ is a hidden folder. Previews and Thumbnails (in the cache) and some other things are also stored in there. The default database is actually created in AppData\Roaming. Camera Modules on the other hand are stored in C:\Program Files.⌠So, even if they are referenced in the database you carry between PCâs, if the item being referenced is missing, your image is broken. You can still work with it, apply DxO standard presets and profiles, modules will be re-installed, but anything custom by the user will be missing.
Using several external drives with one computer seems to be fairly straightforward in comparison to working with one drive and multiple computers.
There is no need to use separate databases unless files and folders share names, in which case the separation helps to prevent certain issues. Starting to use an external derive with several computers provides additional issues that have been discussed extensively.
Easiest way would probably be @John-M 's way of working. Quit PhitoLab and delete the darabase before switching.
but most of the file management software I use treats it like any other directory, possibly because I set an option to allow system and hidden files to be visible somewhere once upon a time!
By default yes and the âCacheâ directory appears to remain there even when you use the DxPL âPreferencesâ to locate it elsewhere, on the N:\ drive (NVME) in my case i.e. here it is still shown in its default location
So I deleted the âCacheâ directory on C:\ and PL8.3.1 started fine and didnât appear to create a new âCacheâ directory on C:.
I just noticed the directory for âToneCurvesâ in that list in the snapshot so that needs to be added to the list in my program, if I ever finish it!
but the âCAFList.dbâ held in C:\Users\bhtho\AppData\Local\DxO\DxO PhotoLab 8\ is also significant.
I donât use LUTs so I am not sure where they come into the list?
You have missed a very important file that handles the âExportâ profiles, amongst other things, namely the one located at DxO.PhotoLab.exe_StrongName_addo3jomrfkt2faiwwfxxb444r1xfvlh in my case which contains the following
Just for your information, with Disk Management you can assign any available letter to a USB drive. Just open run from the start menu and type diskmgmt.msc followed by enter.