This is exactly what I am experiencing on my M1 MacBook Pro with PL6 Elite. What I also see is that PL6 adds a record in the database to my developed photos (jpeg and TIFFs). Sometimes I develop a few images to decide which one to keep. When I am deleting, by Finder, not used developed photos the same issue as above occurs… I don’t want PL6 to keep a record of my developed photos. And any changes to photos are on the RAW file, not the jpegs or TIFFs… The library module of PL6 is not good enough. All other parts of PL6 are very good, but not the library module… DxO should, in my opinion, put some more effort in developing the library module…
@joanna & @platypus Created a project and moved an image from A to B but the cache still contains the thumbnail etc.
So with DxPL shut down I changed the name of the cache and got this via a ‘Project’ I set up before moving an image.
Please note that I always seem to get an ‘!’ not ‘?’ !?
I attempted to delete the project entry and got this
and then
but I can also attempt to locate via a ‘Search’
and deleting them produces this
and this
in the database.
Repeated:-
Like an idiot I repeated the test but this time just changed the name of the image but left the DOP and xmp sidecar in the directory with the original name and so began a new saga!!
Sometimes I got no error on deletion but nothing changed i.e. the icon with the ! remained intact and other times I got this
UNITL I changed the names of both the DOP and the xmp sidecar when the deletion went through successfully.
Yet more “odd” code why do the sidecar files have to be absent to delete an image entry which has already vanished - answer - because someone coded it that way!!
It could be argued that the “wayward” image might return “home” sometime!! but that’s 45 minutes of my time I won’t get back (I am slow after three trips to my son’s house this week helping give moral support and hold the door linings and … and drive 60 miles into the outskirts of London and then back again, one trip was more about aquaplaning then anything else !??)
@thomasev Welcome to the club some of us have been complaining for a long time, @platypus at least 6 months more than me.
My experiments are not to “vindicate” DxO but rather to test the boundaries of what is currently in place and possible. In addition there are differences between the two versions of the product which doesn’t help matters.
The ‘Expunge’ database entry would fix this issue by “bypassing” what I consider to be flawed code, apparently flawed on both systems but in different ways? But I think that DxO should fix the code
- On the Mac so that a simple deletion is allowed to proceed.
- On Windows so that the discovery of a DOP or xmp sidecar files does not impede the deletion that would otherwise seem to work
But that then raises the issue of what should be deleted, just the database entry or the database entry and the DOP and the xmp sidecar file given that the image has “run away” anyway.
An ICloud issue experienced by other users meant that when an image was spirited away to ICloud leaving an orphaned DOP then DxPL(Mac) removed the DOP so there was no hope of repatriating the image with its DOP!
Personally I would prefer DxPL to leave the user to clear away any genuine debris and in the above example allow the’Remove’ command to clean up the mess in the database and leave the user to clean up the mess on disk.
There will always be a risk with proprietary sidecar files like the DOP-files and even XMP. If I export an ARW-RAW that has a DOP and an XMP Photo Mechanic will keep all three files together in an export (if it is properly configured) but XnView like many other softwares will not if I use Copy or Move.
This is why old proprietary sidecars are a risk.
… but just opening files from within XnView or any other viewer with “Opening with Photolab.exe” is really something else since it just makes Photolab open and read all selected image-, DOP- and XMP-files from the folder where they all are stored.
We all have to stick to and respect the way Photolab works. That means that we should let Photolab “own” the file management. The problems with orphans in the database are mainly created by manual actions outside Photolab so doing so is really a bad practise. Deleting databases are too unless you don´t intend to use the Image Library at all. DXO ought to give the users a choise to do that in a more controlled way by adding a new switch for that in the “Preferences menus”. Of compatibility reasons DOP-files might be used only if the ImageLibrary-database isn´t used at all. There should be no need at all for the use of DOP-files if the ImageLibrary is used. That data could like with Capture One and Lightroom be stored in the database. As DXO have done now they create a lot problems for themselves by having to keep all these datasilos in sync and apparently they have some problems with that.
It shouldn´t need to be any science to let Photolab make a fast cleanup when the user opens a folder (delete orphans, append new and update the others). It´s three SQL Queries to run on max a few thousand images which is nothing for an SQL-system. The rendering of new previews would take far longer time. But as we know since other treads the ImageLibrary-database is very archaic. DXO doesn´t put it to work all that much.
You can´t have a database like this without tools to secure the data integrity and those tools has to be automatic and work silently in the background and nothing the users should need to worry about.
Users deleting ImageLibrary-databases is such a low water mark of database maintenance. This is nothing users shall ever have to do in order to be able to work efficiently.
1 Like
@Stenis and FastRaw Viewer comes pre-configured for DOPs and was always configured for xmp sidecar files
Agreed
and therein lies the problem. Yes we should but not when it is minus the command set of even the free image management programs. Basically it is just short of being completely useless!
Hence for any meaningful re-organization users step outside DxPL to accomplish the re-organization and there lies a “bear pit”!
“The throw away the database and rebuild” works except that ‘Projects’ and ‘External Selections’ will be lost and so will data if the user is not vigilant and doesn’t understand the first discovery “rules”!
Many users have spoken about having an option to “not use” the database and seem to completely miss the point that the product is built around the database. DOPs are “simply” the last Audit image of a potential audit trail of database updates but the database is first and foremost the way that DxPL works. It “fails” because its search engine is not (yet) powerful enough and it fails because there is no reconciliation procedures to help resolve the garbage collection situations discussed above.
With good image management facilities the issues would diminish and with additional database management facilities the final holes would be plugged.
The DOP is where DxPL raises itself above some other packages because in the event of a catastrophe there is a way out, except for ‘Projects’ etc. because no-one at DxO could be bothered to write the code!
The second day of my testing with LR the database failed with corruption and those test edits never saw the light of day again!
There is nothing really wrong with the way that the database and DOP mechanism works and I personally prefer it to the alternatives BUT
-
Without adequate image handling facilities within the product users must resort to other means to accomplish major re-organizations.
-
Any coding peculiarities and bugs could be resolved with database utility commands (like removing the database entry but leaving everything external intact), but they don’t exist.
-
The DOP versus database Uuid, which is there to protect the sanctity of the edit data, leaves users up to their eyes in the mire with “Unwanted Virtual Copies” from time to time.
A simple message that a problem exists as soon as DxPL detects the issue with an offer to use one or the other (database or DOP) or both (database and DOP or DOP and database) edit details would resolve countless hours writing posts etc. etc. but getting DxO to listen is like … words fail me (they don’t but I can’t write them here).
Regards
Bryan