I’m using Darktable (DT) Version 5.4.1 on Windows 10. When I started DT today all of my libraries/collections were missing. It was as if DT had never been used to edit anything. In my case, I probably have a different setup than most people. The program is installed on a thumb drive and I have my own custom scripts for starting it. Because thumb drives are pretty slow for writing to I use command line parameters that specify where the database is to be located which is on a normal hard drive. The database looks like it is located where expected but I’d like to confirm the location being used by the running program. Is there a way from within a running instance of DT to identify and confirm the specific file (e.g., library.db) that is being used?
I’m not an expert and note I’m in Linux not Windows but I think the principle will stand.
I ran darktable from the command line with the flags -d all appended to the end and with the output piped to a file as it produces a lot of lines.
I use the flatpak version of darktable so my run command is:
flatpak run org.darktable.Darktable -d all >debug.txt
Open debug.txt in an editor and search for data.db.
On one of the lines it appears to show the location of which data.db is being used.
0.2363 [init sql] library: /home/phil/.var/app/org.darktable.Darktable/config/darktable/library.db, data: /home/phil/.var/app/org.darktable.Darktable/config/darktable/data.db
The problem seemed to magically just go away and when I subsequently started DT it was back to what I’d call normal.
I have a theory on what may have happened. Something that happens fairly often in Windows is that when you close a program, especially if you do it by clicking on the X icon at the top right of screen, the window gets closed but the process simply becomes unusable but is left running even though it is consuming no CPU power. I think this can have the effect of retaining whatever locks are placed on the files it was using. Then when restarted the previously used files remain locked and are unusable in which case DT would have to revert to an alternative.
While this would be a Windows rather than DT problem it does provide a good reason why it ought to be possible to locate the files being used from within a running instance of DT.