If I understand well, this prevents the use of a backup when database is used ?
How can this be conceivable ? No backup possible (and worst : backup created but not usable !) ?
Tell me I’ve missed something … This can’t be possible ? This would be totally amateurish and deconnected from reality …
@JoPoV I believe it is correct from the work I have done in the past and just repeated above!
Please note that I might be wrong!
I have started testing Mount Points but made the fatal mistake of closing a mounted drive without first closing (removing) the mount point!! However when I got that right it seems to work as I expected (and previously tested).
But using Mount points needs to be done before discovering the images via the mount point, i.e. with Mount Points the mounted drive can be accessed directly or via the Mount Point but only if accessed via the Mount Point, which can then be used by another drive, can drives “share” a single UUID in the database!
The alternative is that the database has to be “rebuilt” using DOPs but any ‘Projects’ will be lost as will any data that was in the database but not “flushed” back to the DOP (an unlikely occurrence if DOPs are being maintained) or back to the image in the case of the metadata (determined by the metadata preferences etc,).
I thought that the backup was one of the essential pillars for a professional work …
But a backup that does not work is the worst trap imaginable …
That can ruin a production, and more …
@JoPoV Presuming that I am correct about the way that it works, which makes sense from the normal running perspective, namely
Each image, even if added multiple times will be treated as independent, i.e. some software seems to treat such “Duplicates” as “versions” but DxPL does not do that, they are all independent!
DxPL can handle different drives being used that may have the same title and Drive letter as a previously used drive without confusion.
but
this requires a unique identifier that can be trusted and DxO have chosen the Volume ID which it treats as a UUID.
However, this UUID is essentially the topmost node of a “tree” that then has images at the leaves and the only way to those leaves is via the UUID. Not completely true because searching goes through the images (‘Items’) looking for matches of one sort or another but the principal method of matching a found image on disk with an image already in the database (or not) is via the “tree”.
But we now have the issue of what happens if the data on disk becomes unavailable for one reason or another?
In my case the directory structure on my backup disks, accessible via the LAN or via a USB3 port are identical to the structure of the original images but on a different disk with a different UUID! The DOPs are exact copies, the xmp sidecar are exact copies and the images themselves are also exact copies and, hopefully, reasonably or completely up-to-date but I cannot simply get DxPL to accept those images as replacements because of this one field in the database!
For other users things might be even more complicated and the backups may exist but not with exactly the same directory structure and how that could be handled I am not really sure!
Realignment for my own particular case is simple “just” change the UUID but for others …
I could use my favourite comment when it comes to many things about DxPL infrastructure handling, i.e. it is a simple job to fix the problem and create a much more user friendly product but my comments have fallen on deaf ears for some years now and I am bored with the lack of response from DxO. I am aware and thankful for the new releases that are coming out for both DxPL5 and DxPL6 but …
In other programs I use, this is called content directory (or other terms). You can move all your project to an other place and only have enter the new content directory for all related files can work together again (and there are a lot (!!!) of files, called by a lot (!!!) of different parts of the project … The begining of the path (content directory - easily editable by the user) is concatenated the other part of the path (the relative path - contained any sort of database). And that’s it. No backup problem, no project relocation problem.
THIS IS BASICS !!! and works like this since more than 30 years with softwares I use ! … Not a really new way of doing things, isn’t it ? no need to be houdini to do that !
Lot of details like this, solved since a while in other softwares, aren’t in photolab. It looks like they leave on an other planet.
I think the same : content directory ! AND database saved with project and not in a user space defined by windows.
I could elaborate, but have not time for this.
In the end, everyone should be generating sidecars as this is the only solid container for your edits that can be backed up and restored without much thought.
In my mind the database only serves as a cache for the information in the sidecar. Of course the fault is certain things like project membership is only stored in the database. So if someone experiences a drive failure, aside from spoofing the old HD’s UUID onto the new disk which I assert is beyond the capabilities of the average photographer, that project information is gone regardless.
Again. In my mind the database is a cache only to speed performance of the tool. The sidecar is the reference…
Perhaps a strong opinion, but in light of this discussion I believe it’s a fair assessment.
You are right it is not straightforward in many cases to change UUID. If your disk is GPT then it is a complex long hex string with no ready tool to change it. Also, if that disk is used for other important applications or as a boot disk - which uses the UUID - then you have further issues. This is not something you should attempt. So there is no database backup solution for a blown up internal hard disk, unless you happen to be MBR (old type PC disk cfg limited to 2Tb) and you’re prepared to get a bit techy. I totally agree that DXO should consider how to improve this. Photo editing takes hours and hours and losing the edits is potentially a reason to change editing software … you’re back to square one anyway …
Do I understand well that there is no way to transfer the project structure to another computer if I want to switch?
But it does not contains everything. Not projects …
Anyway, work half done is not done !!!
This is what I understand too. Informations in the database, can only act on only one drive. If this drive has a problem, even a backup does not work. You have to tweak database file the hard way - need to like going into and modify ascii (I hope) lines of codes.
There is no problem with informations in sidecars (.xml, .dop).
I think you can manage to have only projects in the database, and other relevant information in side-cars.
Their project structure is still next to useless for me until they allow manual sorting, but before they add any new features, DxO should really make it a priority to implement a proper backup strategy. At the moment, noone can seriously recommend using ther projects. This is baffling, as they have even added some new features to the projects with PL6. In retrospective one must be happy that the projects are next to useless right now, otherwise many would have done a lot work organizing their files for nothing.
That’s a real problem but currently unless you want to hack a replacement drive’s GUID there is no way to restore project information to another disk…
Anyway there is another topic which is about being able to use PL across multiple systems and in that I suggest attaching the project information to the sidecars is my preferred option…. Feel free to vote for it.
Came across this (elderly thread) by chance and had a look into DPL’s database on my Mac.
All volumes encountered by PhotoLab seem to be added to the database, even temporary items like the “Install Nik Collection” drive and other drives that I’ve removed quite a while ago.
The good news here is, that the listed unique IDs (rightmost column show) are the IDs that macOS has assigned to the respective drives. Replacing these IDs in the database should reroute DPL to the changed location, unless other hooks are used in other tables of the DB (have not checked for this).
If I were in the situation of the OP, I’d backup the DB and edit the ID and drive name fields.
I’d probably also remove the deleted volume’s records, hoping that they are only stored in this table.
But again: DxO should make PhotoLab sustainable by adding the necessary capabilities to (manually) fix lost relations, automatically create (compressed) DB backups etc. Corresponding feature requests are available - and have been for a while.
Caveat: If other locations (folders) have changed names, these locations need to be edited too.
