Cache file

I’m trying to find out what is contained in the cache file. Setting up my photo files and database on an external ssd so I can switch editing between desktop and laptop. Do I also need to move the cache file to the external drive? Photolab 5.

The cache is used to speed up image rendering - - PL keeps a store (aka “cache”) of previously rendered thumbnails, and it uses them to display the Image Browser … rather than re-creating each thumbnail each time.

So, no - you don’t need to move the cache to your external drive … PL will rebuild the cache, as required.

John M

1 Like

Thanks John. Any disadvantage to having cach file on the external drive.

I don’t believe you have a choice in that regard, R … You can set the location for the database (See General tab in Edit / Preferences), but I don’t know that the cache follows that location.

In any case, no - I doubt you’d actually notice any real performance hit.

In my personal workflow, I delete both the cache and the database just before I invoke each new PhotoLab session (but that’s because I don’t care about any of PL’s DAM features - and I don’t expect PL to manage my images for me).

Regards, John M

Cache path can be set. I suggest NOT sharing one cache between two computers. Let each computer manage its own cache.

Are you sharing the database file? I wouldn’t recommend that either. Share the dop files and let PL pick up changes.

1 Like

I’d agree, if DPL actually read all the stuff from the .dop files. As of DPL 5.1, this is not the case.

Good to know. The photo files will always be added and updated on the external ssd. I assume the database file should be ok to leave on the ssd. I’ll leave the cache file local.

What changes doesn’t 5.0 pick up from the DOP file?

Read this for more information:


I agree with your recommendation, Mike - - but, I’m not aware of ability to set the cache location in any case (unless it follows the location set for the database ?)

Yes, that’s my approach - but one needs to delete the database between PL sessions in this case, else PL will generate unwanted Virtual Copies, as its reaction to what it will see as duplicate correction details.

John M

@riverman: Would you please update us on your success (or otherwise) of running PL on 2 systems with shared storage - as this is a common question on the forum and we don’t have a definitive solution for this as yet (in so far as I’m aware).

Also, are you on Mac or Win ?


I’m still not clear on whether to turn on Metadata syncronization in Preferences.

I was using a windows 10 laptop with PL4. My new desktop is windows 11 with PL5. Copied my photo directory onto the external ssd. Set database location to the ssd in PL5. That seems to be ok. As soon as I feel brave enough, of have enough :beer:, I’ll upgrade the laptop to PL5 and use the external ssd.

Working on photo shoot for a hotel here in Cuenca, Ecuador so I’ll try alternating importing and editing between the 2 computers. Will post success or otherwise.

1 Like

If you switch MD sync on, DPL will do whatever it does, without giving you any chance to intervene.

If you want to be in control, switch MD sync off and read or write MD when appropriate.

  • Manually read MD if the image has MD added by an other app (e.g. DPL on your other computer)
  • Manually write MD after editing MD and you want that edit to be seen by other apps
  • Decide which edit is more important - if you accidentally edited MD on both computers

I’ll leave syncing off for now and see how that works. If everything saved to the database should be ok.

@Riverman I don’t know what platform you are working on, Win 10 or Mac. I thought there was an issue with the Mac that the database location could not be specified but that is possible with the Win 10 and may have changed on the Mac (anybody?).

John-M made a comment with respect to the risk of the creation of Virtual Copies in any such “enterprise”.

The Win 10 Preferences option allows the database file to be specifically defined but that does not move the cache files which will remain in C:\Users<Username>\AppData\Local\DxO\DxO PhotoLab 5\Cache where ther are two subdirectories a Previews and \Thumbnails.

In two posts Synchronise PhotoLab - #26 by BHAYT and How to use PhotoLab on multiple Apple Computers - #58 by BHAYT I describe the issues that can create Virtual copies and also how it might be possible to avoid them.

Edits are stored in DOP files and these are essentially copies of data held in the database. If PL5 is being run on 2 systems there will typically be 2 databases one on system A and the other on system B and these will effectively point to the files on system A and on system B respectively. If any files are moved from B to A or vice versa (A to B) along with their respective DOPs then a Virtual copy will be created on the receiving system iff (if and only if) that system already has an entry in its database for that file in the given directory and the DOP does not have a unique identifier (Uuid) that matches the receiving database!

If this occurs then the receiving database preserves (protects) its existing data and it is marked as the [M]aster copy and the incoming DOP is used to create a Virtual Copy [1], in this way PL5 preserves both sets of data but there is now the issue of “cleaning up” the database to remove any unwanted Virtual Copies.

The best way to handle this is to avoid VCs if possible!

Essentially moving an SSD between systems where both the PL5 database and the files and their DOPs and any xmp sidecar files all reside should not cause any VCs to be created but to avoid many duplicate entries in the database the way each system refers to the database and the files should be the same, i.e. it is possible to have the same photo in the database many times over providing they are held in different directories and that will happen if System A has the SSD mapped as drive E:\ and System B as F:. In your case it would be useful not to have this situation but rather to have the same drive letter assigned to the SSD on both systems. e.g. they both “see” the SSD as F:\ for example.

Arguably you cannot relocate the cache file and theoretically it should not be a problem just moving the data (database, Photos, DOP, xmp sidecar) should allow rediscovery to take place or the elements of the cache will age and the new data will stored. Unfortunately I have seen a situation where PL5 showed an incoming directory with the same thumbnails as a previously deleted directory but this vanished on restart. If the drive letter is the same on both machines it may well simply re-use items from the cache, albeit there will have been updates of the other system etc. I have not done much work with the cache so I cannot give a definitive response to questions about it, i.e. about the cache.

There is a problem in choosing not to ‘sync’ metadata @platypus. Please note that PL5 will update xmp embedded data for JPGs (no xmp sidecar will be created) and create an xmp sidecar for RAWs) it will not update embedded metadata within the RAW files).

The ‘sync’ option effectively causes PL5 assigned metadata and externally assigned metadata to be merged. If that option is not set then metadata can be read into PL5 where it will overwrite any entries in the PL5 database or write the metadata where any metadata externally assigned (not in the list from PL5) will be lost. Please write in your response how you intend to manage your metadata, e.g. all in PL5, all externally or a mixture of both. There is currently no way to “merge” metadata except using the ‘Preferences’ ‘Sync’ option! I have been requesting such an option for months @sgospodarenko.

Now we come to the potential problems with PL5 itself. If you use ‘Ratings’ there has been a change between PL4 and PL5. In PL4 the ‘Ratings’ data was held and read from the DOP. In PL5 it is stored in the database and written back as xmp (sidecar or embedded as appropriate) to the photo (or xmp sidecar etc.). It is also written to the DOP but is not read back from there. Hence, you should treat the photo = photo + xmp sidecar at all times.

With the Tag there is a problem explained in one of my posts here PL5 Tag Field not read from .dop file - #93 by BHAYT. Basically the Tag is a piece of PL5 metadata but not xmp related, hence it does not belong in the xmp (embedded or sidecar) data. As such it is stored in the DOP and was read and written successfully in PL4 but in PL5 it is not being read back from PL5 DOPs (this is a bug).

I have included the above two items even though they should not really impact your data move because the data and the database are essentially staying together; all that should be happening is that a PL5 program on machine A or on machine B opens the database on the attached SSD and uses it as if it is the only machine responsible for that data and database. Please do not run PL5 without the SSD correctly attached because it will ty to make a new database!

It is possible that I have missed something please update the above @sgospodarenko

1 Like

On a Mac, the database can be moved or copied to a different location (when DPL is not running) and the respective preferences file edited to match the new location. It has worked in a test, but I’d not expect this mod to be sustainable under all conditions.

Manually reading/writing/syncing sidecars is not easy and can’t possibly prevent unwanted results, specially with the current implementation of what info is transferred by DPL. It takes some concentration too to do the right transfers. I ran a few tests which mostly worked as expected, but I’ve not run systematic repetitions and have not completely documented the steps because I’m still managing my images with my SPOD, which is Lightroom. I’ll stick to Lr until DPL gets proper DB management. Maybe we’ll get there in 2-3 years.

@platypus Thank you for your update. I reran a previous test which is similar but not identical to the @Riverman proposal, namely I made an update to a photo on my Main machine (A) closed down and opened on my test machine (B) and changed the database name to the database on A, i.e. mapping the drive containing the database and data across the LAN.

Closed and restarted PL5 on B and found the updated I had made on A and shut down. Opened on A an applied a preset to the next photo and shut down on A. Opened on B and there were Virtual copies for both photos with the first showing the same thumbnail odf the preset applied on A originally but the second photo showed the original as [M]aster and the version with the prest applied as [1].

I had this before and cannot understand why this happens when effectively only one database is responsible for the management of Uuids. I will repeat this tomorrow (sorry later today) with cleared databases and a small test directory and track Uuids in the database and DOPs to see what is happening.

Bye for now"

@platypus @Riverman I have abandoned the test that caused VCs i.e. B sharing A’s database and photos and will investigate that later.

Instead I tested the scenario that @Riverman really wants to run, i.e. transferring the database and the photos and “baggage” (DOP etc) on an SSD between two systems.

Disclaimer: I don’t work for DxO nor do I know or understand the working of PL5 beyond what a lot of tests and results have taught me (providing I interpreted the results correctly - of course). I did nothing special with the Cache because there is no way that I could! The tests were reasonably short and sweet so I would suggest that you repeat them with larger quantities of data just to be sure but it appears that what you want to do works O.K.

Test scenario:

  1. 2 x Win 10 systems my Main machine PL5.1.3 and my Test machine on PL5.1.2
  2. Re-format an old SSD connected via a Sabrent SATA cable
  3. On the main system I used Zentimo to configure the SSD to always connect as T:
  4. Added photos to T
  5. Opened PL5 navigated to T and configured PL5 to use a database on T:
  6. Restarted PL5 and checked database open on T, made edits to 1st and last of 5 photos.
  7. Closed PL5, stopped T in Zentimo and disconnected Sata SSD
  8. Connected Sata SSD to USB on Test machine
  9. Set drive to be T: on Test machine with Zentimo
  10. Opened PL5 and navigated to T: and configured database to be on T:
  11. Closed and Restarted PL5 and navigated to T:
  12. Repeated editing on Test then Main a number of times, all edits visible and no VCs.
  13. Started PL5 on Test while Sata SSD connected to Main and PL5 (on Test) defaulted to the default database location and that was shown in the ‘Preferences’ database location!

Please Note: All edits were to make the photos stand out in the thumbnails not to “improve” their appearanace!!

Essentially it works fine but how you set the fixed T: (or whatever) without Zentimo I do not know and Zentimo is good for forcing the closure of attached devices. It is using features in the operating system so other utilities or the commands in Win10 will be fine (I have been using Zentimo for a long, long time and forgotten how to do it “natively”!). If you are using a MAC then …there will be the equivalent but I do not know what they would be.

The testing was not without incident I had PL5 dump on my Main machine and restarting PL5 said the database was corrupt and it was going to fix it! During the final test of B sharing A’s database and photos I had PL5 open on both machines at the same time (unintentionally at first but every time that PL5 on A (Main) updated DOPs new VCs appeared on B(Test)). So I suspect the dump and corrupt database came from that situation.

After that everything went as @Riverman hoped for a number of disciplined transfers between the two machines!

First and last edited on Main, second and 1st from last edited on Test, T: back on Main machine:-

In Windows, right-click the Start-button and select the Disk Management utility … then right-click the storage device that you want assigned to T: … and select Change Drive Letter.

May I ask for the short version, Bryan;

Were you able to have two machines working with the same/shared database and same/shared file-system without PL reacting by creating Virtual Copies to resolve (what it deems to be) duplicate sets of corrections?

And, were you generating sidecar/.dop files in the process?

John M

@John-M, @platypus, @Joanna. @sgospodarenko
Shared directories in a shared database do not work because the PL5db stores then as separate entries but the DOPs then overwrite each other and … chaos and an abundance of Virtual Copies.

The tortuous workings out that led to this “obvious” conclusion.

I have always thought that the test where A (main) hosts the Photos, DOPs etc. and the database and B(Test) accesses the Photos etc. across the LAN and is configured to use the same database as A should work. I have tested this previously and then again last night/early this morning and got Virtual Copies.

Hence, answer to your question, both machines are reading and writing DOPs and after the initial parts of the test I start getting Virtual Copies.

I need to test again with multiple snapshots to make sure both machines are “reading from the same hymn sheet”.

Then I need to see why there appear to be “clashes” between the database and the DOP (other than the obvious - that I have not got the setup right) particularly in light of the Sata SSD test which appears to work. Other than a BHT error the main difference is complete separation of the two environments, i.e. T is either attached to A or B not A but B can still see A but why would that make any difference.

Thinking about it ----- the Sata Test has both A and B seeing the drive as T:, the Lan test has one seeing the drive as F: and the other mapped as V: but … I need to attach the Sata SSD to A, share it across the LAN and configure both machines to access the database on T: and repeat the tests, starting with T: photos in their current state with DOPs and then add another directory with just Photos and check out as many scenarios as come to mind, snapshotting all the time and making sure only one PL5 is active at a go.

If the tests fail I may have to upgrade T to 5.1.3 but I will do that only as and when!

I actually ran the test below and now believe that there are two sets of entries being stored in the database and the writes are back over the same DOP!

Hence, Virtual Copies are inevitable because PL(A) and PL(B) are sharing the same database but not the same entries for the “same” files but they are then overwriting each others DOPs and therein lies chaos!

The chaos on PL5(B) with the directory from the original test.

Test Scenario:-

  1. Configured sharing on T: attached to A
  2. re-configured PL5(B). i.e. database on B, to be T: on A
  3. Restarted PL5 on B and navigated to photos on T(mapped to T: on A)
  4. Navigated to folder and all O.K.
  5. Changed an edit on first photo and closed PL5(B).
  6. Opened PL5(A), checked using database on T:
  7. Instant VC on all photos in the test directory the first photo shows original as [M] and the change(B) as [1]. The others have [M] and [1] the same.
  8. Set up more test directories on T: with only photos present
  9. Opened and closed PL5(A), no DOPs created
  10. Opened PL5(A) and forced DOPs on all photos and closed on A.
  11. Opened PL5(B) chaos with test directory from above test.
  12. Navigated to new directory and forced DOP export.
  13. Closed PL5(B).
  14. The DOPs do not match so VCs are assured!
  15. The database shows entries for the drive being ‘local’ or ‘network’!!