Using PL6 on two computers, with duplicate image collection

This concerns the use of PL6 on two computers and while I think I have found an answer, so much of the information ‘out there’ is older and/or contradictory to some extent - hence this post.

I have a laptop and a desktop which can be connected via a broadband router, but there is no separate server and they are not always connected to each other. Both are Windows 11 and they each contain a full set of images and sidecar files (dop, xmp and such like). Both sets are synchronised each way using synchronisation software and they use an identical folder structure, both on an additional drive d:. The synchronisation process works fine apart from user error when I have adjusted the same image in two places!!

The process does not sync anything that is only contained in the PL6 database, of course. When I look at the contents of the dop it seems that all adjustments, tags and keywords are recorded, including for any variants. My Projects are lost, however, and that is not surprising. I renamed the desktop database folder and copied across the same folder from the laptop. It opened fine but when I selected a project, the images were shown ’!’ original unavailable - so I’m guessing that it is looking for the laptop d:\ and not just the ‘local’ d:. So, syncing the database appears not to be an option and nor, therefore, would sharing it on, say, a removable drive.

I understand the possibility of putting one image etc. collection on a removable drive and plugging it into whichever computer I am using - but that seems inconvenient and carrying around the main collection with latest adjustment files seems inadvisable.

Have I understood this correctly? Why is it so (Capture One is totally tolerant of synchronising the database … but they have abandoned me as a user with problems so I have to reconsider the association)? Is there a technique that will achieve my aim, or some other workflow that effectively achieves it?


@roadcone It should be possible to maintain two copies of images, each with their own database, on two systems. Please refer to Unwanted Virtual Copies and Moving DxPL edited images (DOPs) between System - Revisited for some work I did that seems to show that the DOP UUID is used when possible on the second system so “A to B” and “B to A” is easy.

The testing also showed that “round tripping” was also possible, i.e. “A to B to A to…”. This all hinges on the UUID of the DOP not changing!

Projects cannot be exported or imported at all and the reason for the failure of your ‘Projects’ is discussed here PL6 cannot find edits after converting Win 11 disk from MBR to GPT and is to do with the UUID of the drive (the VolumeId)!

Do you understand the “first discovery” rules with respect to whether metadata is taken from the DOP or the image (embedded or xmp sidecar) when a DxPL “database” encounters a “new to it” image?



PS:- This may or may not be relevant Fresh new database and project start

I do this between desk and laptop’s. I use a program to copy changes between the two and as I don’t use the database delete it on both regularly. You must only edit one then copy changes across. I edit on the laptop when away and do a final edit/weed on the desk top and never had any problems buy only as I don’t use the PL database. I use separate DAM and use it for project’s not PL.

BHAYT: OK … read the one about the UUID and understand it. My only risk is to the Projects as I have always used dop files. And for those files which have been edited in Capture One I have added a suitable keyword - multiple keywords. For example, the 16x9 desktop crops have the keyword 16x9CO … etc. So even if the database fails, I should be able to keyword search to reconstruct some of the Projects. This is still a ‘work in progress’ but is getting there.

Aside: Capture on v21 allowed drag-and-drop from a third partly application into an otherwise empty Album (Project in PL6 terms). I am using v23 with problems and have discovered that this facility was ‘lost’ in v22 and that there are no plans to ‘find’ it. The CO approach is quite dismissive to these problems - “it is not a resource priority” and they suggest a workaround that is wholly impossible on an existing collection with a mature folder structure. So … PL6 gets ever closer as my tool of choice.

Your link to Unwanted Virtual Copies did my head in! I need to read it again after a lie down!

No, I don’t (yet) understand ‘first discovery’ - first contact, yes, but not discovery! (Though dealing with CO Customer Services is a bit like First Contact) I guess it will be in the manual.

John7: Thank you for your comment. For the moment, I am using a database to provide projects. If I can get the keyword situation tidied up then they can be used in a search and make the need for projects unnecessary. I have a project for images that have been edited in Capture One. Not that the edits come over, but I want to be able to know later which application contains the original edits for a given image if I need to make adjustments. For the moment, the last thing I want to do is repeat thousands of CO edits in PL6 just to ‘tidy things up’.


BHAYT: I’ve just read something on the “Fresh new database and project start” link. The bit that says PL6 database can handle different disks with identical folder structures and image content - as in Master and Backup. This ‘could’ be my situation with laptop d:\ and desktop d:\ except I have copied the laptop database to the desktop and that has not entirely worked.

What if … I accessed the desktop d:\ from the open laptop PL6 (which I can do because I use that connection for synchronisation) - would it then be possible to copy the database from laptop to desktop given that although the mount point for desktop d:\ will be different from the desktop than it is from the laptop, the UUID will, of course, be the same?


@roadcone Clive I will try to respond tomorrow and help with what I can, if you think reading such posts is hard work imagine doing the research and then writing them up!


Bryan (if you use @BHAYT) when responding I will get a notification and can run away… sorry!

I was going to suggest that as a “cunning” plan!

DxO have a similar ethos when it comes to implementing some of the easier fixes they could implement, resources are finite but …

Basically when users have copied images and sidecars, xmp and DOP, from one system (A) to another system (B) they have been able to add them to the DxPL database on that system (B) but when they try to bring them back to A (“round-tripping” the images with the latest edits) they are greeted by DxPL adding the latest edits as Virtual Copy [1], hence “Unwanted VCs (in the bagging area)”.

The ‘Virtual Copy Topic revisited …’ was exploring how often this happens, given that I had worked out the mechanism that caused the issue, namely the Uuid held in the last part of the DOP.

Actually every user created (or system created) Virtual Copy will have a such a Uuid and these Uuids must be unique for every image ([M]aster or [VC] ) within a database!

Early reports seemed to indicate that this seemed to happen all the time i.e. any sort of “round-tripping” was going to result in VCs but the research for that topic seemed to indicate that DxPL used the original Uuid unless that Uuid was already in-use in a database!?

If my research was correct then copying and adding to another database on another system is possible and so is bringing the updated DOPs back to the first system, more often than not!

‘First Discovery’ is simply a shorthand way of describing the situation of “automatic import” used by DxPL when it encounters an image in a given directory that it has never encountered before, i,e, a first for that database or a “new” to that database image is “discovered”.

DxO changed the way they handled DOPs part way through PL5 releases but implemented the change in what I consider (not that I or my opinions should count for anything) to be a very clumsy way and the “round-tripping” or repatriation as I have also referred to it elsewhere can fall foul of the “rules”.

This Unwanted Virtual Copies and Moving DxPL edited images (DOPs) between System - Revisited - #18 by BHAYT references another topic in which I looked at the “first discovery” rules and their implications for handling metadata from either the image (embedded or xmp sidecar) or from the DOP.

Basically the the rules that govern whether DxPL detects external metadata changes and reads (embedded for JPG, TIFF and DNG and sidecar or embedded for RAW) and writes (embedded for JPG, TIFF and DNG and sidecar only for RAW) updated metadata from the image also controls what DxPL is going to do on ‘first discovery’!!

Please see attached (1.3 MB).

I did some testing on this way back, i.e. accessing across the network, but before I understood the implications of the UUID in the ‘Folders’ structure which means while a user thinks things are working DxPL has simply imported the images again and any existing projects will fail and those “imports” will be subject to ‘first discovery’ rules and …!

I currently have three machines under my desk, with a bit of room for my aged legs, warm in Winter but too hot in summer (on some days), all connected via a gigabit LAN, which is how I do synchronisation.

This post has taken my allotted time for the day, I am trying to stop an old wooden lean- to from rotting completely and giving it a new coat of paint before the weather breaks! Will try a test when I can!

PS:- Networks are handled differently but your proposal is to copy the database from one machine to another please spell it out for me so that I can recreate your exact process between my two machine (System 2, - still my Main Machine and System 3 - my Test machine)!

The snapshot shows two mapped drives, one on my main machine (Mediasys) and the other on a NAS (DS220J) being accessed from DxPL6 on my Test machine versus a local drive (F:)


Please don’t do any more testing on my behalf. Overnight I have worked out the flaw to my plan. Whereas a database on the laptop that knows about the local disk and the networked disk will work fine when located on both computers (it will use whichever bit of its database it needs), Laptop Projects will not be seen on the Desktop (and vice-versa). And any Project changes I make on one will not be seen on the other - so even if I manually align them on Day1, they won’t stay that way.

The keyword approach, while a bit clumsy, will work and like all workflows, when you get used to it, it becomes second nature and no real impediment.