Hold your horses… On a Mac, “Advanced History” shows all edits even after a DPL6 restart.
Indexing the photo archive on the new machine should work to a) import all settings from .dop sidecars and b) metadata from the original files and .xmp sidecars…but history will be lost, as it’s only stored in the database…
One way to get previous edits, metadata etc. is to back up the “old” database and restore it on the new computer, but again, history comes along on Macs only. Luckily, @bjnelson works with Macs.
I’ve restored backups of databases across machines and as far as I remember, things worked as expected…which does not mean that it will do so in any and every case. You can’t lose trying it though.
I can see a possible problem with this approach; if the file structure on the new PC was different from the old PC (as references within the database would be confused).
In your case, however, I gather you’ll simply be moving the external SSD across to the new PC - so, its file structure and references within the database will remain consistent … provided you attach it with the same storage-system reference (assuming that’s how it works on Apple gear).
As Mr. P notes; it’s worth a try.
Before you do so, tho, I suggest you switch the first of these options (Save settings …) to OFF;
just in case PLv6 decides to update your sidecar/.dop files in some way that you do not expect or want
switch it back ON (assuming that’s how you normally work) when you’ve confirmed all is good.
Also, you may not need to install PLv6 on the old machine just in order to save the db - It should (?!) work to save the database (on the old machine) from PLv5 - and then restore it on the new machine (with PLv6) … Again; nothing to lose by giving it a try.
@bjnelson This is not a trivial topic and this is not an easy response because there are or could be many caveats. I believe that your “best” course of action is to copy the files and DOPs to the new SSD and introduce that to the new machine but you will lose certain things (some of which may have been “lost” already)!!
Having posted this, it is way too long @bjnelson please DM me so that I can direct you to the bits that might fit you scenario or help evolve a suitable scenario!!
I believe that is utter rubbish, in the worst case “just” “discovering” your old directories on the new machine, with the new DxPL release and a new database, directory by directory should resolve things essentially as you go iff (if and only if) you have AS(OFF) (‘Auto Sync’ = “unselected”! see the following for an explanation
Because the import process is tied to the image discovery process then just opening a high level directory does not initiate an import of all the sub-directories, otherwise users might never be able to start using the product while it imports every image (431,301) images in my case!!
In fact having an empty database and directories full of image files with DOPs is fine. When you are interested in editing a directory opening it will populate the database but only to the extent of the contents of that directory!
@Musashi It should be unnecessary for a user to come to the Forum because there is no written procedure for executing the move to a new computer or a change of hard drive albeit one set of instructions for each platform please!! That written procedure would then be available to the DxO support team who would be able to guide the user appropriately! Instead of some “half-truths” that are based on anecdotal “evidence” of what users have or have not or might have experienced in the past.
I am fairly aware of the issues surrounding elements of this process on my Windows machines but do not own a Mac (or two) to test out the correct strategy and there is no-one from DxO present in the forum any more. I want to be able to throw facts back at @JoJu instead of “listening” to his remarks, which sadly have an element of truth in them, and not be able to adequately rebut his claims.
Plus I feel the strain of writing this document without any form of backup from DxO personnel whatsoever!!
Back to the Task at hand!
One problem is that if you have already installed PL6 on the new machine then some of the automatic migration actions cannot occur. the opportunity has come and gone!
I have discussed these in greater detail below and it depends what you want (or need) to preserve and what you are prepared to “recover” by manual intervention!?
“At risk” are
The edits (not really at risk)
The export presets (may already be lost! Uninstalling PL6, copying the correct directories to the new machine (you might need help from the Mac experts) and re-installing PL6 might resolve that!? )
‘Projects’ if you have any they should be recoverable by loading an old copy of the database in PL6 but they will be pointing to images located on the old drive what will happen when you move drives is …!
‘Presets’ would have been carried over if PL6 had been installed on the PL5 machine or it might have been possible to copy PL5 data to the PL6 machine and then install PL6!
Metadata should have come along with the DOP “for the ride” and will be loaded automatically when directories are discovered or when the PL5 database is loaded into PL6 see earlier chart for details
.
I believe but cannot be sure that the biggest “problem” will be moving the data to the new drive which would certainly cause an issue with Windows!
More details:-
I can only comment on what I have found “playing” with DxPL(Win) but, hopefully the Mac experts can add to what I write and put the Mac slant on things, i.e. correct things which are different on the Mac.
Arguably regardless of which platform you are using the following are the things that might be most “precious” and which it would be good to have carried over and/or be able to recover:-
The edits:-
Which are contained in the database and should be up-to-date in the DOP.
But while later releases can read earlier DOPs it doesn’t work the other way around! So, arguably, once PL6 reads a PL5 DOP then that DOP is “suitable” only for that PL6 release.
In truth, on DxPL(Win) the urgent “need” to update all DOPs appears to have “vanished” in later releases and they seem to be left alone until an edit or a metadata change is made in PL6.
So if you are going to move to a bigger SSD it might be worth copying all your “old” DOPs to the new drive and
Either use the new drive with PL6 (keeping the old drive as backup), I believe that there will be problems with the new drive that I will address in a minute.
Or use the old drive with PL6 (keeping the new drive as backup initially but there may be problems with Volume Id when it comes into use!)
Or simply abandon any use of the old database and the old drive and copy the files to the new drive and use that to populate the PL6 database from scratch
and please note
The export “presets”:-
Which on DxPL(Win) are kept in the Config file and each new release (including interim releases) reads the old config and creates a new one. Without an old config when you install a new release the export “presets”, amongst other things, are lost and DxPL will revert to the standard default exports.
‘Projects’:-
‘Projects’ have no external existence, their only home is the database and without a database to use when installing the upgrade release the automatic upgrade will not occur. However I believe that a database backup can be “imported” at any time (it can on Windows) and DxPL will undertake any “conversion” automatically!?
Presets:-
‘Presets’ are automatically copied by the installation process from the PL5 location to the PL6 location (and converted?). If the presets are not available during an upgrade then this will not happen!
I compared my PL5 presets with my PL6 presets and almost all (in fact I believe it was all) had been copied over without change. But you would need software to be able to merge the old presets with the new, which in this case will only be those supplied by DxO!
DxPL(Win) will detect all the presets when restarted and they should then all be available for use!?
Metadata:-
‘Metadata’ can reside in the database and (optionally) also be written back to the image. If it is in the database it will also be in the DOP. If AS(OFF) is “set” then all new “discoveries” of image data and DOPs will use both the edit data AND the metadata from the DOP as per the chart earlier.
Volume Id.:-
‘Volume Id.’ may only be a Windows “thing” and is “explained” here Fresh new database and project start - #3 by BHAYT but the DxPL(Win) database contains a ‘Folders’ structure (table) that holds the details for a Volume.
This Volume Id. is assigned when a directory is formatted on Windows and stays the same on the drive/partition/directory unless deliberately changed by the user with “special” software!
This issue with the Volume Identifier means that the current drive should be fine when presented to the current database in PL5 or PL6, or so I “guess” and have verified in testing with DxPL(Win).
However, when the contents of the drive are copied to a newer drive, which on Windows would have a new Volume Id. then it would not match the “Volume id” in the ‘Folders’ structure and DxPL(Win) will treat it as a new drive!
The existing database entries will be left (“impatiently”) “waiting” for the “old” drive to return but new entries will be created for the ALL the images on the new drive. Any ‘Projects’ would be relevant only to images from the old drive, i.e. essentially none at all and all data used to populate the database would come from the image files and their accompanying DOP as follows
Edit data is always taken from the DOP regardless of any ‘Preference’ settings
Metadata will be taken from the DOP only if there was any previously and then only if AS(OFF) (please see above!) or if the ‘Import’ command is executed but this should be unnecessary.
You already threw back 1730 words (in one post). I’m just waiting to see if the dust settles anytime soon to read some of them, but although I know books offering less to read than your posts @BHAYT I also know books more effortless to read than these post-monsters (in my language).
@mwsilvers it was a cold(ish) day which started out sunny, i.e. gardening or DIY would be possible but turned very grey and with it my “urge” for both sank so I decided to make things even worse by embarking on that post!!
The OP uses Win computers. Some things that apply to DPL on Mac don’t apply to DPL on Win , differences have been listed in this thread: Differences Win / Mac
@platypus I know, but most of the differences being logged are about features and facilities and differences in appearance and function and are important to better align the two versions.
But my main concern in this case is how the workings of the products differ, e.g. a database location that is “hard-wired” on the Mac but configurable on Windows, which is mentioned!
In the context of replacing the computer and then replacing the drive my concern is about what can be done to recover presets, export options but particularly with respect to introducing a new drive to an existing database, regardless of how that database comes into existence, i.e.
Using an old PL5 database as input to PL6
Using PL6 to discover images and the DOPs having started with an empty database!
The Uuid contains the Volume Id for my F: drive on which my image files etc. reside. In my tests on Win 10 I used 2 USB 3 SATA SSDs with identical names and drive letters and directory structure and images but DxPL(Win) was perfectly happy because it used the Uuid (Volume Id) to differentiate between one and the other.
If DxPL(Mac) uses an analogous field then what I tested will continue to work on the Mac but that means that copying from one SSD to another will not “work” because DxPL will detect the difference in the “Volume Id equivalent” and treat the copy as a new drive, i.e. abandoning the current entries and “simply” rediscovering anew.
Hence, save the database and do whatever you need to on a Mac to start with an empty database and discover the new SSD and start processing the images as and when desired!!
Even when cloning drives the software I use offers the ability to copy the drive Id (which I presume is the same thing!?) as part of the clone operation but does not recommend doing that!
The product I use to access the database is DB Browser for SQLite and is available for the Mac and appears to be compatible with M1/M2 hardware if you want to look at what is in the ‘Folders’ structure!?
@platypus thank you for testing and with respect to the data I would hope that was the case, with DxPL(Win) it copies the database to the current database location and then “finds” it after a restart!
That means that the edits and metadata (also in the DOPs) and projects (if any), essentially the most important elements of the editing data, are preserved.
That just leaves the following, which actually might not be an issue for @bjnelson
When these are available then DxPL will upgrade/update from one release to another but they typically will not be present on a new machine and the upgrade cannot take place!
Finally there is the question of the new SSD.
I have taken my research a step further by cloning an SSD drive to another SSD and setting the option to keep the disk id. but have “discovered” that the field being captured by DxPL(Win) is the “Mount Volume id” assigned by the Windows operating system
i.e. the Uuid field enables DxPL(Win) to keep the data separate even though it is identical between the two SSDs (with respect to the directories discovered in DxPL).
If I detach P: and attach the clone drive and discover in DxPL then there is no change in the ‘Folders’ structure, i.e. the system and DXPL has accepted the drive as it would the original
So I believe a simple copy will result in the new drive being seen as a new drive and DxPL will simply absorb the images and DOP and create new entries, on Windows in particular but a clone might get away with the “subterfuge” and simply be accepted as the original.
@platypus yes on Windows we can locate a database anywhere but I tend to use the sidebar and it will put the database in the location that I have set for the database in ‘Preferences’, and in the above case this is actually on the default drive (SATA SSD).
My concern with what you tried is whether DxPL(Mac) will pick up the old SSD of @bjnelson without “discovering” the images and any associated DOPs afresh, which believe it will!?
So
When an (or a?) USB drive is attached to a Windows machine it will be assigned a drive letter and may also have a label.
When the user opens DxPL(Win) and navigates to a folder of the newly attached USB drive DxPL needs to know if it has seen that drive before or whether the drive is actually new to DxPL, i.e. should everything that is “discovered” be treated as new and the “new discovery” rules that are now associated with the AS(ON) versus AS(OFF) status will come into play!
Because drive letters and labels can change the deciding factor about a new drive versus an “old acquaintance” is controlled by the Uuid in the ‘Folders’ structure shown in my earlier post, not by the drive letter nor by the label but by the Uuid value.
Hence the “fuss” that I keep making about the Drive (Partition) Uuid. If it changes then DxPL believes that it is dealing with new data and starts populating the database with all the new data that is discovered.
But if it recognises the Uuid as being one in the ‘Folders’ structure then it expects to be able to use all the references in the database, e.g. Projects should point to already discovered images and DOP Uuids should match database item Uuids for each and every image that is being re-discovered by DxPL.
Hopefully discovering the old database should work when the old USB drive is attached.
But if those images and DOPs are copied to another larger, faster USB drive then there will be problems. The new drive will have been allocated a Uuid when created and the copied images and DOPs will be treated by DxPL as “new” because the Uuid of the copy will not match anything in the ‘Folders’ Table.
The consequences
Any and all projects might show a thumbnail but will indicate that the image is missing, the pointers are to the old images which are on the old USB drive (with the old Uuid)!
The old image entries in the database will be side-lined waiting for the old drive to re-appear.
DxPL will happily discover the “new” data associated with the new Uuid and all will appear to be perfect, just that the database will be somewhat larger than it needs to be and any projects won’t work until the old drive is restored.
Hence, my experiments with “cloning” using Farstone (not to be confused with FastStone) which appears to be a Windows only product.
It seems (more testing is required) that a cloned drive has the same Uuid as the original drive, i.e. the system and DxPL can’t tell the difference so DxPL will adopt the new drive as if it was the old one even if twice as big and twice as fast!
If there are no projects then you might as well just copy the images to the new drive (with the DOPs etc.), start with a new database and let DxPL discover the data afresh whenever (if) you visit “old” directories.
DPL on Windows allows a few things that do not work with DPL on macOS.
If we could (on Win) drag the photo archive root to the new drive (possibly while pressing a modifier to make a move instead of a copy), DPL would reconnect the folder(s) to the new location (volume).
Not having a Win computer makes all of the above a guess…that might be worth trying though.
@platypus DxPL(Win) barely wants to copy anything I believe! It will copy images (drag and drop) and move images (Shift + drag & drop) but not directories I believe and that would not help with ‘Projects’ because I don’t believe for one moment that DxO would have built in the necessary fix-up code given that there is no way of recovering project data anyway.
@Wolfgang thanks for the input but that moves images not the directories themselves. Interestingly I tried moving 3 images to a newly formatted USB drive and got
@Wolfgang please explain your post a little because I am unclear as to what you mean exactly?
Providing the user has ensured that all edits and metadata are in the DOPs then the simplest process is to “start again” with a sparkling new database but for users who use projects that could be a “disaster” unless someone writes a utility!
I realise that many laptop users process their images from USB drives, with interfaces that are getting faster and faster, albeit on the very latest laptops. So there is the requirement to be able to move to a new and faster machine and/or new and bigger and faster drives.
In fact if I was using my machine seriously for PhotoLab work, I am in the process of walking into the problem myself because I am rejigging my HDDs moving from a 6TB to an 8TB HDD, with the 6TB then replacing a 4TB as the overflow drive.
I am about to walk right into the drive Uuid “problem” as I try to replace the 6TB drive with the 8TB and cloning is not a realistic prospect for a drive that big and I would lose some of the swing space that I need to accomplish the migration!! Hopefully the 8TB drive will arrive for the Test machine in the next few days but that won’t fix this issue, nothing short of the ability to re-assign the Uuid can fix my problem.
However, my database is transient, projects are (currently) transient so …
With a new database on a “new” drive there is no (urgent) need to re-discover data (i.e. trigger an automatic import) until the user is going to re-edit images and the “only” risk is that there is no backup, to the DOP data in particular, some users destroy the database on a routine basis anyway.
The user should always ensure backups that include DOPs and xmp sidecars as a routine matter.
But I truly lament the lack of written procedures, the lack of additional utilities e.g. to export the projects so that they can be re-assimilated/recovered and the lack of training for support personnel which is beyond …
I have cleared another old SSD so will try a clone without keeping the disk id to see what difference, if any, that makes.
How easy is it to clone on the Mac? I used to have mixed success with various Windows utilities, mostly cloning boot drives but Farstone cloner (Free version) has been ultra reliable for me!
Yes, one has to create the new location for the files (outside or inside PL – I’ve done it both)
and then can move pics inside PL, so that PL keeps track.
When I did so, PL also kept the relation from the source file to its output →
PhoLab’s just another word for nothing left to lose 
I also know books more effortless to read than these post-monsters (in my language).
