I believe DxO has not all entries:
MacOS
select count(*) from ZDOPFOLDER;
1130
Windows
select count(*) from folders;
1477
@RobiWann Well one of the databases is rather light on âFoldersâ entries but please remember that you are counting the number of âFoldersâ, i.e. âF:\A\B\C\D\a.imgâ will get 5 entries in âFoldersâ, one for "F:", one for âAâ, one for âBâ etc. (and one entry in âSourcesâ and one entry in âItemsâ and similalrly on the Mac with âadjustedâ names.
Hence, my desire to code the reconstruction of the complete entry from the âFoldersâ structure to get a meaningful count and determination of what is present and what is missing!
My photo archive contains about 30k image files and is indexed within 30 minutes. I index the whole lot only from a clean database, one that was created new by DPL after having renamed the present DB.
I also leave DPL index without interactions ! from my side and times have been quite consistent so far. I often also prevent the system from sleeping, using the âcaffeinateâ command in Terminal.app (ctrl-C to de-caff the system)
At the end, the bar will stop moving and if it doesnât, something is wrong. Maybe you can run a few tests with a subset containing e.g. 1000 images (-> 1 minute) and see what you get. Then delete the database and repeat the test. You can check runtimes by looking at the create and last update timestamps of the DB in Finder.
As always: Make sure to have a working backup before testing!
What I mean is, to open another database you have to copy existing database to another directory and copy a previous database back to the standard directory in order to open a different database. Or, change the preferences to point the database directory to a different location (windows only).
A simple solution is for PL to have an option to open a different database.
@KeithRJ Sorry but not if you are a Windows user, in fact I believe that a Mac user can do exactly the same thing, i.e. use the âRestoreâ database function.
The one thing a Mac user cannot do is actually relocate the database to another location, it must always be in the standard location to be opened,
On Windows you can also relocate the database to any drive as I did in my example, i.e. I relocated to N:\ and started running the database there.
But the âRestoreâ is effectively a command to open another copy of the database, one you saved on some previous occasion with whatever name you chose to save it with.
It does require a restart and the database name will be PhotoLab.db but when you have finished with that copy simply do a âBackupâ to whatever name you want and wherever you want and then âRestoreâ another named database with any name, but it will be copied as âPhotoLab.dbâ to whatever is the current location of âPhotoLab.dbâ and you will require a restart to use it.
Effectively DxPL is doing most of the leg work you are suggesting a user has to do.
PS:- If you are careful you can have many generational copies of the database but there will only be one DOP for an image, even if that image has been opened in many databases over time it will contain the details from the last database that it was opened with.
@BHAYT I am NOT talking about the restore function but rather shutting down PL and moving databases around and then starting PL again.
The location can be changed for DPL on Mac by editing DPLâs settings file or by relocation as @KeithRJ proposes. The name of the DB file(s) must be unchanged though.
@KeithRJ I am still confused by what you are actually trying to achieve?
What I have described is doing what I believe you want namely
just that!?
Arguably there is no reason why DxO couldnât open any DxPL database on any drive directly, certainly on Windows, with their given name, but they have chosen not to do that and on the Mac they wonât even let the user set an alternative location for âPhotoLab.dbâ, the only database name that DxPL will work with for processing.
@platypus I have seen your suggestion of what you have to do on a Mac before and not all users will or should have to hack the system in that way but you have found a workaround for that particular element.
So in my case I could move the database to my NVME, which I choose not to use as a Boot drive, even though it is the fastest drive I have by a long way.
However, both versions allow the âRestorationâ of any database to processing at any time and the user doesnât have to move anything, DxPL will do that for them.
Please describe how what you want canât simply be achieved using the âBackupâ and âRestoreâ function on both a Mac and a Windows system.
The functions could simply have been called "âCloseâ or âClose asâ and âOpenâ because that is exactly what is happening.
Arguably the âBackupâ is intended to allow a copy of the database to be âsquirreledâ away in a different location before closing down for additional security but can be used as I am suggesting.
But how does what @KeithRJ is suggesting any different to what I am proposing can already be done?
Possibly my brain is wired differently and I canât see the obvious but to me the use of the âBackupâ and âRestoreâ functions provide what I believe is being asked for, namely I can save a database with any name to any location at any time and open a database with any name from any location when required.
Albeit it will then be known as 'PhotoLab.db" for as long as I choose to use it before I save it ('Backup) and move on to another database copy (âRestoreâ).
Backup and restore can certainly be used and with backup, we can set a custom name that says something about its purpose.
Things could be much easier though if DxO added a feature that lets the user select a DB either by presenting a dialog or by being able to launch DPL with a double-click on the respective DB file. Iâd also welcome an ability to launch DPL with whatever the name of the DB file should be. (Lightroom can do it 
)
There are currently a bunch of workaroundsâŚthat donât work because DLP forces things to be located and named as set in its settings file. DPL also sets the database to open with a DB browser (if present) and when I change this setting, itâs overwritten the next time DPL opens.
@platypus I agree but the current use of âBackupâ and âRestoreâ can be used more imaginatively than just for database security backups, as well as for database security, if the user wants to use the database long-term, of course.
indeed, but the restore sets the name of the DB to default as set in the preferences file. This means that itâs not easy to see on what catalog/DB one is working. When I occasionally test with Lightroom, I can use or create a catalog that isolates the test from the prod catalog which helps to keep the catalogs in good shape. Keeping good shape is difficult with DPL, which gobbles up everything that it accepts as an image.
@platypus Agreed and I did make that point in an earlier post but it doesnât just set the name to the default it actually copies the database to the default location leaving the original intact in is original location.
Remembering the origin (name and location) of the database that is in use is not aided by this process at all.
My major issue with DxPL is the automatic ingestion of a directory rather than being able to simply view a directory and then selecting to import/ingest the directory into the database.
I like and hate the automatic import function in equal measure. It is what drew me to OpticsPro in the first place but it means that I need to review images in one product and then carefully navigate in DxPL to avoid importing images into the database!
Sadly my favourite viewer, FastStone cannot successfully pass more than one image to DxPL at a time, it actually passes them all but in such a way that only the last one is opened in DxPL! Plus my tests with FastRawViewer and XnViewMP seem to top out at about 350 images maximum.
This is not entirely off-topic, anymore than these discussions about opening different Catalogs/collections/databases are off topic, i.e. both are, oops!
So we canât retain the name of the original database nor adequately control the images that will be imported, it is the whole directory or none at all.
Other than that things are perfect.
Returning to the OP topicâŚ
Database restore can restore database backups and databases right from the operational folders of previous versions of DPL.
While DPL (Mac) can import older databases and migrate them accordingly, it remains to be seen whether that import function also covers databases from DPL (Win).
@BHAYT and myself are in a private discussion that has brought us forward to the following:
According to my tests with DPL8 on Mac, we can make DPL export .dop files (sidecars) so that they can be read on the new computer, no matter if some development settings and metadata have been changed or not
The following concept applies:
- In DPL, select a folder (without image files) that encloses folders with image files
- Set DPL to auto-export sidecars and disable auto-import
- Quit DPL
- Edit the DPL database, preferably by machine-filling the respective cells
- Save the edit and close the DB
- Open DPL
- Index the folder (without image files) that encloses the folders with image files
â In my tests, the sidecars appeared as I was hoping.
Once @BHAYT has been able to verify the procedure, we can describe the procedure in detail. For those who think that they know what to do and how, be my guest and test the procedure - at your own risk - and having made sure that you have backups, should anything go wrong.
Because the databases are different in so many ways it is highly unlikely unless DxO deliberately set out to put such code in the product. If they did I feel that it would be very âoldâ but just in case here is my Test database I used for my test, complete with the flags set.
PhotoLab.db (166 KB)
With respect to @platypusâs âcunning planâ nothing seemed to happened when I ran my equivalent tests on PL831(Win). The fields remained set in the database and no DOPs appeared whatsoever!?
Trying to restore the database (with extension changed to .dopdata) throws an error message. DPL (Mac) canât restore a DB from DPL (Win).
This needs to be retested, @BHAYT changed the procedure.
Different procedure â different result?!
1 Like
@platypus and @BHAYT - Thank you again for your interest in solving my problem somehow. DxO Support had no interest in this.
This is not possible. Of course, I tried that first
I think in the end I only have 2 options.
- I activate the product under both MacOS and Windows and try to find out which files were edited and do not have a DOP sidecar file.
- I give up completely and try to sell my DxO customer account (I have just written to support about this)
DxO cannot index the directories completely. I donât want to spend days making SQL queries to find out exactly whatâs wrong or to transfer the directory list from the Windows table to MacOS.
I think itâs a shame that the developers at DxO lack the necessary foresight for such a job, but I canât change that.
By the way - DxO under Mac also handles softlinks differently than under Windows.
@RobiWann I am sorry we were not able to offer an easy solution but for the sake of completeness
@platypus I documented my procedure to you in detail and the only real change was making the database fix with DxPL open but on a completely independent directory.
So I repeated the test, shutting down the application and the DB Browser software after every stage.
So we have
-
Set up 4 subdirectories 2 x 3 images and 2 x 2 images, the 2 x 2 image directories are by way of a control group.
-
With DxPL NOT running I used DB Browser to set the flag on the first 6 images i.e. Folder 1 and Folder 2 and wrote the changes back to the DB
-
Closed the database browser and re-opened and checked that the fields were set and then closed DB Browser again.
-
Re-opened PL831
-
Indexed the master directory of the 4 test directories and there are no DOPs in Folder 1 or Folder 2 (or 3 or 4) and a search on âFolderâ in DxPL
found the following
-
The flags remain set in the 6 âSourcesâ entries.
-
Added another step and re-indexed the individual directories but with no change.
Of course it is possible to create the DOPs using the âSidecarâ'Export functionâ but where @platypusâs procedure only requires re-indexing at the highest point in the directory structure the âExportâ function must be executed one directory at a time.
The only deviation I made from the @platypus test procedure was him shutting down the application when hacking the fields and in my case I had left DxPL running but on an unconnected directory as I have done in many tests before.
In my revised procedure I shut down the database between each step so the database was never open by more than one program at a time.
1 Like
Okay, letâs say that the procedure works with DPL on macOS but it wasnât confirmed with DPL on Win, which would be the necessity to make sure that .dop files are written on Win for import on Mac.
This means that we can use the procedure for migrating from Mac to Win, but, unless otherwise confirmed, not for the migration from Win to Mac. For those who want to check it out, the recipe follows below. The cells that were edited are shown here:
RECIPE
- Select a surrounding folder containing folder(s) with test images
- Quit DPL
- Edit the database and set said cell(s) to 1
- Store the entry and close the DB
- Open DPL
- Index the surrounding folder â .dop sidecar(s) appear
Note: Follow the recipe to the letter, any change of the sequence of steps can change the outcome. Again, the recipe was tested successfully with DPL8 on macOS. The DB browser I used to edit the cells can be found here: Downloads - DB Browser for SQLite
Test setup: Cells set for several images of two test folders. DPL set to auto-export sidecars only. Iâd not set auto-import, even though the database is supposed to have the most recent customising and metadata (unless one edited dop-files manually).
Just repeated the test with a different set of images. Check out the .dop change date:
Of course, things would be nuch easier if DxO did something for platform migration.
1 Like
Have you changed the option (in preferences) to specify that Sidecar/.dop files are NOT to be exported for each source image ?
- Otherwise, why would a sidecar/.dop file NOT exist for each edited source-file ?