Hopefully someone has a suggestion for my problem.
I run PL6 on Windows 11 and I have to date not used sidecars (that will now change!).
My Raw files reside on a 4Tb disk, but as this disk was configured as MBR it could only see 2Tb. When the disk filled up, I used a 3rd party utility to convert the disk to GPT on the fly, leaving everything else the same (no changes to volume letter, label, or directory structure). The conversion to GPT just allowed the system to see the full 4Tb of space.
Since then, PL6’s database cannot see the edits of the files on this disk. It works as before and can see all other files and related edits on other HDDs where I have Raw files. But on this 4Tb disk no edits are shown. Searching the web and the DXO forum I see that PL6 uses the GUID to identify the disks where the raw files reside to find the right file and match to the edits in its database. I suspect Win 11 changed the GUID when I converted the HDD to GPT. As such, PL6 no longer find a file match as the path is now different.
This is highly frustrating - and clearly my fault - but I didn’t realise that PL6 used the GUID, I merely thought the directory path would be enough. Any ideas how I could rectify this? Losing +1000 edits would be a shame indeed. As I have no sidecar .dop files for these edits I cannot rely on that. If there is a way to edit the PL6 Database file and change the GUID reference that could possibly work? If so, has anyone tried this? Any suggestions would be much appreciated.
Thanks Wolfgang. I think I need to either find a way to change the GUID/UUID reference in the PL6 database or to change it back in Win 11 for that disk to the old UUID reference (if that is possible … GPT and MBR may have different UUID format). But then I need to find a way to see that in the PL6 database … unless I am on the wrong track here … I will try DXO Support and google some more.
I think it’s rather crazy that The database uses the guid and doesn’t make any attempt to reconnect the drive when the guid disappears.
This is a flaw in logic in my mind. If I have to replace a disk and can transfer all the data over, it doesn’t matter, the database ignores. This is wrong.
I can only suggest make sure the sidecars are created and safely stored. This is the only sure thing. It’s also why I really wish that all data associated with an image is stored in the sidecar. Like history and project membership.
Yes clearly sidecars is a must and I have started using those. Then the core edits are transferable. But that doesn’t solve my problem. The UUID for an MBR format is shorter than the GPT format, so editing it to point the catalogue to the files will have to take place in the PL6 Catalogue. Does anyone have any experience in trying to edit the Catalogue? If it has a table with disk references I may be able to fix this by changing the UUID reference to the ‘new’ GPT disk?
Yep - ticket has been raised. Really frustrating this … I have now exported to sidecars for all my other files on the other disks, and enabled them in preferences. But still, 8 months of 2022 stuck in limbo in the Catalogue
Yes - and not made clear. You really need to use sidecars - it should be a clear recommendation. That disc holds all my 2022 photo trips (>20,000 Raws with >1,000 edits). I started to use sidecars from October … and those files have their edits so it doesn’t seem to use the same validation there - probably just matching file names.
Ironically I was in the process to manually exporting all my edits to sidecars when I expanded my disc
Sidecars are associated by file name.
The database basically disregarded all of your old images. And when you selected the old folder the program found the sidecars and applied the edits it found in the sidecars…
Anyway I suggest everyone use sidecars. I actually pack the sidecars into a zip file when I archive a project. If I ever need to work on an old pic, I restore it to a new folder and extract the sidecars and can edit it from any location without regard for where it was previously.
In my mind, sidecars are the only way. But that’s just my mind. Clearly others do things differently.
Well maybe … but still strange and a risk to historical edits. What is the purpose of the database when it cannot preserve your edits if disks are changed? As demand on RAW file sizes increases and more photo data is added, we often upgrade disks and other computer elements. If the RAW file edits are hard-linked to a disk’s UUID then you’re losing all your edits if the MBR/GPT UUID changes - that is not helpful.
This is why I keep saying that all image edits and history should be in the DOP file and nothing else. And all the meta data should be in the XMP file. Only then should the database read those two files and update itself for DxO’s housekeeping.
I do have to ask why you think you need a persistent history? I have never used it in all the years it has been available. There is no sequence to PL edits and, to my mind, no reason to undo sequentially.
Yes I think nobody disagrees with you - that, however, is not the problem this thread is trying to resolve. I need to find a way to ‘spoof’ the UUID on the PC … or some other way to make the database link files and edits … any ideas welcome