That confirms reports by others I’ve seen on problems encountered when attempting to share databases amongst multiple devices.
So, conclusion for @riverman; you could run multiple devices against the same set of images - BUT, you would need to delete the database before each invocation of PL - and use sidecar/.dop files to retain your correction details … (This is my approach, even tho I don’t use multiple devices.)
The downside is that you would lose ability to retain keywords - and you cannot define Projects … as these details are not held in sidecar/.dop files.
The answer is no, deletion is not necessary, according to my tests!
The @Riverman proposal is to carry the database and photos etc. from system to system, not reach across a LAN or copy files etc.
So I carried out a lot of tests for “How to use PhotoLab on multiple Apple computers”, wrote a procedure for synchronising between computers based on ideas others use about deleting and replacing images documented at Synchronise PhotoLab - #26 by BHAYT.
From the tests I have carried out (standard Disclaimer at this point)
Copy files and DOPs etc. from one PL5 system to another where the directory/file combination is unknown - O.K.
Copy files and DOPs etc. from one PL5 system to another where the directory/file combination is known - Virtual Copies
Open a database and files across the LAN and attempt to edit different sets of directory/file combinations on each machine accessing separate combinations but never simultaneously on more than one machine - O.K. (I surmise but haven’t tested)
Open a database and files across the LAN and attempt to edit the same sets of directory/file combinations on each machine accessing the combination but never simultaneously on more than one machine - Virtual copies (Tested above and in the multiple machine Topic)
Accessing a database and files on a NAS - failed with PL5 permissions issues with my DS220J NAS
Accessing a database and files on a third machine from two other machines i.e. the third machine is acting as a NAS but without the permissions issue - O.K but following my results from the test above in this topic I need to check under what exact circumstances that appeared to be the case!
Using a delete before add strategy used by other forum user posting to the multiple machine topic and then a related strategy using directory name changing and documented by me (reference above in this post) - O.K.
Carrying the database and files from machine to machine on an external drive (e.g. a Sata SSD) - O.K. in my tests above in a post in this topic but with each machine mapping the external SSD to the same drive letter - need a bit more investigation i.e. check the database to make sure that the test is not “faking good”, what happens if the drive letters on the two machines are not the same etc. I can guess at the outcome but I have been caught out before!!)
PS please be aware of a bug reported by others and recently retested by me where the ‘Tag’ (accept/reject/untagged - green/red/grey) which is metadata unique to DxPL is not being read back from PL5 DOPs documented here PL5 Tag Field not read from .dop file - #93 by BHAYT.
Based on your findings, Bryan - - if db is not deleted then won’t PL generate VCs, as its reaction to resolving duplicate sets of corrections ? … That’s what I understood you to be confirming - No (?)
You are absolutely correct if you have a duplicate set of data which is actually duplicake, i.e if any situation arises where the same file in the same directory that is also found/presented/navigated to etc. where the Uuid does not match between the DOP and the database then both copies are kept by virtue of the Virtual Copy mechanism.
So all my tests and my summary above and my posts elsewhere have been about avoiding this situation at all costs because as you rightly say when it occurs there will be VCs but only in the replicake situation where the k represents a non matching Uuid (and potentially a “shed load” of changed edits elsewhere in the DOP).
But people are keen to be able to takes images out into the field to edit during their down time and also take new images and edit those and then bring all back home and merge them together and take them out into the field on their next trip and … repeat the cycle. Is any of that possible and the answers are yes “sort of” and the “sort off” is the results of my tests summarised in the post above.
Your approach of deleting the database is perfectly acceptable if PL5 is only used for RAW editing when the DOPs hold all you need.
But are there any alternative ways and the answer is maybe if you can live with the workflows I have tested and found to be O.K., iff (if and only if) you can trust my tests and my testing procedures.
If not (particularly if the alternatives are too easy to make a mistake) then live with VCs or delete your database which suits your and potentially other PL5 users’ workflows.
Please note there is always the database backup command - start each “merge” cycle by backing up the receiving database. If is all goes wrong then use PL5 to import the backup (Restore) and do it all again! …and again…and again…until you get it right or decide to change the strategy
I think this is what I do. On my laptop I keep the current and last 3 years photos with all kept on my desktop. When away I edit (not using deep prime as that’s hopeless on the laptop) and use Photo Supreme. On return I copy over the new image’s and do any final editing. Photo Supreme adds any new keywords etc. when I add them to it and PL is no problem. I keep all the image’s including any changes to those from the laptop up-to-date between the two when at home. I do not have any projects and use Photo Supreme as DAM. So far the threatened permeant history has happened to windows so I don’t know what might do to this system. But I have never had a problem but clearly I am not using one data base but two and even within them I delete them every few weeks anyway as they slow up PL loading and are of no use to me as my system relies on the dop’s and not using pl as DAM.
Yes - that’s the simplest and safest approach … assuming one has no interest in keywords and the concept of projects (neither of which is held in the sidecar/.dop files).
I think projects can be created in Photo Supreme and copied over between PC’s along with keywords via the xmp files (pl reads the keywords and geo tagging) so could well be other DAMs would do the same
@John7 and @John-M you are both avoiding the problem in your own way and there is nothing wrong with that and you have a workflow which neatly avoids the problem.
My alternatives (providing I have done the testing and describing correctly) also can work.
However, as I have written elsewhere @sgospodarenko, more than once the real fix is to extend PL5 slightly to provide facilities to allow replicake images to be reintroduced to the database without causing VCs, i.e. a warning and override on a
individual
group
directory
session
preferences
etc basis with options to
Make replicake the database entry
Keep the existing entry and reject replicake
Use a date timestamp with all, … to inform the user and prevent the wrong decision.
Allow both to be kept selectively, i.e. the classic VC situation
any other options I have missed
In the meantime keep deleting the database and avoiding the problem but there are (just) other options.
PS In the event that this happens or a user has been using VCs for evaluating editing possibilities it would also be useful to have a “promote” function to allow a VC to replace a [M]aster copy and also to allow swapping and re-organising the VCs to create an evaluation order for VCs.
@sgospodarenko Help requested not to fix a problem but to comment on a test which has me puzzled .
In my response to @John-M and @John7 in response to an original query from @Riverman I put together a list of ways that I had investigated to avoid the “unwanted Virtual Copies” situation.
However, in the light of my results for the test @ Cache file - #20 by BHAYT where the two directories were being held separately in the database leading to DOPs being overlaid and VCs resulting I was concerned why my test @ Cache file - #18 by BHAYT had worked!
i.e.
So I tested the situation and it continued to work even when I changed the drive letter on one of the machines, please note that the change of drive letter would affect the location of the database as well as the files!
While I am glad that this works and means that a hard drive containing the database and images and DOPs etc can be transferred from one machine to another I do not understand why PL5 is recognising the directory whether the drive is mounted as T: or Q: and realigning the database in line with that discovery?
Test Scenario:-
So the Sata SSD was already connected to the Main machine (A) as T: and a new directory was “discovered” and the Tag was set on all files in a directory to ‘Reject’ (‘Red’), PL5 was closed and the T: drive was also closed and detached from machine A.
The Sata SSD was then attached to machine B and PL5 started but that caused a problem because iPL5(B) was configured to access T: across the LAN. PL5(B) reset the database location to the default so the location was changed in the ‘Preferences’ to point to T: and PL5(B) closed and restarted.
Navigating to T: located the original database entries with the Tag set to ‘reject’. The noise reduction on the two RAW images in the test group were set to DeepPrime and PL5(B) was closed and the database showed that the drive was opened as Local Disk T:.
The drive on B was then changed to be the Q: drive and PL5(B) opened, it defaulted to the default db location, but that was then changed to the Q drive and PL5(B) closed and restarted. Navigating to the directory now on Q: still located the data that had just been on T: as hoped but not necessarily as expected - no VCs were created!
While I am glad that this works and means that a hard drive containing the database and images and DOPs etc can be transferred from one machine to another I do not understand why PL5 is recognising the directory whether the drive is mounted as T: or Q: and realigning the database in line with that discovery?
@BHAYT this behavior of creating VCs is a known one and expected.
But we agree that in some cases it’s not clear for the user why you these copies are created and there should be a way for the user to cancel their creation. We have some ideas but let me draw @StevenL to your suggestions:
@sgospodarenko thank you for your response. I don’t want the feature to be changed but I am confused (not an unusual situation these days but …) and it would be nice to have that confusion resolved.
