Due to recurring posts about using two computers to manage and edit images, I conducted a test that I documented below. The motivation was to find out, what such a configuration can do and what it can’t.
If you want to replicate or extend the test (see Unanswered Questions), you’re welcome to do so at your own discretion and risk. If you do, post your test (procedures and findings) to this thread. Important: Read carefully before jumping to conclusions.
All that follows was done with this setup:
Computer 1 (C1)
macOS 12.6.8 on iMac 2019
DPL 6.9.1.56 as well as DFP6 and DVP4
Computer 2 (C2)
macOS 13.5.2 on M1 MBA 2020
DPL 6.9.1.56 without DFP and DVP
Config details
Fairly fast USB Stick (for Folder X with 60 test photos) attached to Internet router
5 GHz WLAN connections to both computers
DPL on both computers set to not automatically r/w sidecars (.dop and .xmp)
C1 Database with 25k images listed C2 database deleted before testing (not while testing)
Both DPLs open and pointed at the shared folder on the NAS
Image Editing: Test procedure and findings (T1)
Edit images on C1, manually save .dop files
Check images on C2 after manual import of .dop files
→ DPL edits showed, DFP and DVP edits did not show, which is expected
Edit images on C2, manually save .dop files
Check images on C1 after manual import of .dop files
→ DPL edits showed, DFP and DVP edits were lost, which is expected
Summary: Edits worked as expected
Keywords: Test procedure and findings (T2)
added a keyword with C1, manually saved the .dop files
Check images on C2 after manual import of .dop files
→ Keyword showed on all images, but the keyword list showed the same keyword several times, but the total number of keywords showed correctly (adding the numbers, that is)
added a new keyword with C2, manually saved the .dop files
Check images on C1 after manual import of .dop files
→ New keyword showed on all images and the keyword list did not show duplicate entries
After a while and testing other things, the keyword list on C2 “fixed” itself partially, which means that one of the entries said it had 60 carriers (files with the keyword) and the other entries had no carriers.
Summary: Keyword editing worked mostly as expected, issues existed and were partially fixed.
Renaming: Test procedure and findings (T3)
renamed images with C1, manually saved the .dop files
Check images on C2 after manual import of .dop files
→ File names adjusted themselves, but the edits did not show.
Changing folders or a DPL restart brought back the edits
Same as above for the other direction.
Summary: Renaming files worked mostly as expected as long as both DPLs were open and on Folder X…and some additional user activity
Overall Summary
Using two computer with a shared folder of images worked well for edits and less well for keywords and renaming under the given test configuration and procedures.
Due to the temporary issues encountered, using two computer with a shared folder of images needs extra care and patience
YMMV as soon as you do this with a different setup. Test before you do any serious work this way!
Unanswered questions
Will this work with a mixed Mac/Win config?
Will this work when different folders are shown in the DPLs?
Will this work with one DPL not connected or switched off?
Will this work when DPL is set to automatically r/w .dop and/or .xmp files?
@platypus I ran some tests yesterday and got mixed results but noticed a lot more “flickering” of screens than I expected!?
I apologise that the following is a long posts but if I didn’t document the test properly I would doubt my own sanity but this is one part of
So my configuration for the tests is
i7 4790K with PL6.9.0
5600G with PL6.9.0
DS220J NAS
Empty databases on both systems in the default Windows location
Both machines were configured for automatic Read/Write of DOPs and auto sync of metadata (during my earlier tests yesterday I believed that both machines were configured for automatic metadata sync but the 5600G, running PL6.7.0 at that time, was not configured that way for the earlier tests)
No app was terminated during testing.
Both apps were focused on the same directory which contained 1 [M] and [1] VC to which a RAW has now been added
The tests were conducted with JPGs, will repeat with RAWs (and xmp sidecar files) later.
Before repeating any more tests I decided to run ‘Folder Monitor’ on the i7 “watching” for any activity on the NAS drive.
Test 1: was to create a VC [1] on the i7 and that was successfully detected by the 5600G
Test 2: was to change the keyword of VC [1] from [M] to [1] and that caused no apparent change on the 5600G.
Test 3: I made an edit on VC [1] on the i7, there was a delay and then that was picked up by the 5600G and that included the keyword change to VC[1]. Keyword changes to VCs are not via metadata but via the DOP.
Test 4: Because of the amount of activity I had seen with screen refreshing I started ‘Folder Monitor’ i7 “watching” for any activity on the Test photo directories on the NAS drive. I then added another keyword to VC[1] on the i7 and that was detected by ‘Folder Monitor’ with a large amount of activity logged!?
Test 5: I terminated PL6.9.0 running on the 5600G and added a comment to the logfile and another keyword to VC[1] on the i7 and the following is from the ‘Folder Monitor’ logfile
Xnview shows the following for the JPG image file which appears to have lost its [M] keyword and gained all the keywords from VC[1] @DxO_Support-Team!?
and 5600G shows the keywords for the [M]aster as all of the keywords that have been added to [1] on the i7 and VC[1} still shows its keywords as [M] from the original cloning operation
@DxO_Support-Team, @Musashi I haven’t a clue why this is happening but I believe that no Virtual Copy ([1], [2] … [N]) metadata should ever find its way into an image except as part of the export process of a VC!?
PS:- Eventually the i7 caught up and started displaying
I have run into similar problems ever since I started using DXOPL ver 3 or 4 as I recall. My versions of DXO PL are Elite and are on windows platforms–a laptop and a desktop. External hard drives are attached to the desktop and contain my backup photo images. .
I have submitted more than one support ticket to DXO over the years. As a general statement, I and other DXO users have concluded that to minimize problems in synching info between actions done on the same files on different computers it is best to use one computer as your master and try and do all of the work on it. I have modified my workflow to do this although I am not happy about it.
My current workflow is as follows:
Download Nikon NEF files using Downloader Pro to my laptop. XMP files are created at the time of download. Preferences in DXO PL are set to read XMP info and add info to XMP files. I cull images on my laptop. I no longer star rate images on my laptop.
I copy the photo image file folders to an external hard drive.
I copy the file folders to my desktop. Do additional keywording. Do Star Ratings. Process selected images in DXO PL on my desktop. Make any needed export files like Jpegs.
Once work is completed, I make backups on my desktop external drives (not the same drive used to load the images to the desktop.)
If needed, I copy the processed file folders to my laptop after having deleted the original versions of these file folders. When I open the file folders I may see virtual files created for some or all of the original images. This happens (as best as I can determine from info from DXO) because the xxx.dop files from my desktop are out of synch (my phrase) with the xxx.dop files on my laptop. This is the major problem I have had.
One user on this Forum suggested that to avoid the unneeded virtual files, rename the file folders once they are loaded onto the laptop. This may allow the laptop to see only the latest version of the .dop files and not two versions. .
You may be able to search the Forum for more posts on this topic as it has come up before.
If you have not already formally submitted your problem to DXO Support I suggest you do that.
@Photoman43 I believe that this topic was created by @platypus to explore whether it is possible to have two databases and one source of data, e.g. on a NAS and process the data successfully from either machine, albeit carefully.
I made some tests where I was not processing the data “carefully” but had both systems accessing the NAS at the same time, with automatic sync of the DOP and metadata turned on. Those tests initially performed well but something then went amiss that I need to review carefully. However I then repeated the test with additional components and wound up with the results I documented above (which might also have been what happened in my original tests).
Th bug that I “found” is a rather profound error where for one reason or another DxPL decided to put the metadata of a Virtual Copy into the metadata of the one “real” image, the [M]aster. I believe that a ‘Virtual Copy’ should be just that “virtual” and that includes the metadata, i.e. image edits and metadata should remain in the database and the DOP!
If a user chooses to copy the metadata from a VC to the [M]aster then that is a legitimate user action but DxPL deciding to “arbitrarily” do that means that there is some very dubious code in DxPL, i.e. a bug and I will formally report it for as much good as that will do!
DxO are currently pre-occupied with getting version 7 ready for release because it is that time of the year!
With respect to ‘Unwanted Virtual copies’ there was a post that ran for a year and DxO never chose to intervene and explain exactly what really happens, and I find that an awful indictment of DxO and that was before they basically vanished from this forum after the release of DxPL6.
This was correct but didn’t have enough detail to stop the next 83 posts over the following year until I conducted some experiments and determined the exact reason Unwanted virtual copies - #86 by BHAYT.
The database allocates a unique number, a UUid to the database entry for any newly discovered (imported) image and this is UUid also copied to the DOP, i.e. the database entry and the DOP match and are in sync at that point in time.
If DxPL ever detects that the DOP has been updated (by timestamp I believe) it checks the UUid as it imports the updated edits and if it does not match the database entry UUid then a Virtual copy will be created, referred to by most users as an “Unwanted VC”, to preserve both the original (database) edits as the [M]aster and the new (DOP) edits as a VC, typically VC [1]!
Whether earlier releases of DxPL always allocated new UUids I do not know but it now seems the case that DxPL will use the UUid of the DOP providing that it is unique to the database.
So when a DOP is encountered in a “new discovery” situation DxPL will use the UUid in the DOP when creating a new database entry UNLESS that UUid is already inuse. In my tests that happens frequently because I tend to use the same images and DOPs but located in different test directories for my tests so each will have its UUid replaced with a new unique UUid by DxPL.
However, that is not typical in normal circumstances and even when it happens is not a problem unless that data is taken back to a system where that entry is already in the database. If the trip to the other system has resulted in some images having their UUid’s replaced then they won’t match the database on the original system if they are taken back to that system (and database) on the same disk in the same directories.!
While my situation occurs because of image/DOP re-use it can occur if images or directories are renamed outside DxPL. The original image entries will remain in the database because DxPL was not party to the renaming/moving process. Now those images and more particularly their UUid’s will “block” the incoming images in their new location and DxPL will allocate a new UUid to any such entries to overcome that problem.
This is actually not a problem unless those images return to a system which already has database entries for those images with the original UUid.
At various points in your description of your workflow is seems that images (and their DOPs) are changing location both between systems and also within a system.
If any such change causes previous entries in the database to be orphaned they will cause any re-introduced images to be allocated a new UUid.
That will not cause a problem on that system but will cause a problem if they return to the original system.
I believe your workflow on the desktop is causing a change to the UUid’s of data you intend to return to the laptop! Exactly at which stage I cannot be sure!
This is fine because the problem only occurs when returning images located by DxPL(Laptop) are in their original location (disk and directory) and the UUid has changed and is now no longer in sync with the database.
If the location is not the same, i.e. the disk and/or the directory have (been) changed then no such “clash” will occur! Other users “trash” (delete) their database on a regular basis to avoid this problem.
Losing (“trashing”) a database is a problem if ‘Projects’ are being used but ‘Projects’ are not carried from machine to machine in the DOP anyway so they have to be set up on each machine independently, or not used at all! That will also happen if the image location is changed because the ‘Project’ pointers will no longer be valid!
Just to make sure: It was a proof of concept rather than a serious test, although it took some effort to go through all the steps. I don’t think that I’ll soon be working on two computers in parallel, also because my main platform is still Adobe’s Lightroom.
The OP and all that follows might give others a hint on how to work in such conditions with DPL on Mac. Not more, not less.
@platypus thank you for the post and I won’t be using it quite this way because I cannot move projects with the DOP or by any other means but since most of my software is on the i7 but the 5600G possesses the more powerful processor and way more powerful graphics card then I either run both and double my PC power usage (and provide a little more heat for my feet and legs, 5600G on the left, i7 on the right) or switch between them.
My NAS is not particularly fast and using the network is faster and accessing from HDD or SATA or NVME (i7 only currently) faster still!
since DxO do not include lists of any reported faults nor do they indicate in the product releases exactly what faults have been addressed by that release, nor do they even bother to put the release number into the code file name nor … sorry it is an impossible/fruitless task to try to change the bad habits of DxO.
@John7 They don’t want to spoil the surprise or that would mean using a joined up support system!
I actually don’t know what is on offer in the way of support systems but some other developers, mostly one person “teams” seem to manage way better than DxO.
@Photoman43 Joseph one “technique” I didn’t mention here is along the lines of your item 6 but goes something like this
Rename the original directory in the database e.g. [name]_Original or _Old or just _O. This operation is quick in DxPL and the old images are still protected at this stage.
Copy your images and their updated DOPs to a directory with the original name (but only if this suits your work flow).
You now need to determine when you “discover” this new copy of the directory and enclosed images with DxPL?
a - If you discover the directory at this point then the old copy in the database will still contain entries with the original UUids that will mean that any images with those UUids will have the UUid changed. This is not a problem unless you want to take them back to the other system!
b - An alternative strategy would be to delete the old images before discovering the updated copy. Unfortunately there isn’t a delete directory command available so select all the images in the old directory and ‘Remove’, this will remove them from the database and delete the image and delete the xmp and DOP sidecars (and yes we have asked many many times for a ‘Delete from DB’ command!)
Note the above strategies are not suitable with ‘Projects’ except that the ‘Rename’ done with DxPL will preserve all ‘Project’ links but the image deletes will then remove them from the database (and the ‘Projects’ if my memory serves me correctly!?)
PS:- It might actually be possible to preserve any ‘Projects’ but I won’t be able to test the procedure until later!
