SUMMARY *** After trying to find out more about bug #484398, i stumbled into another one. I changed two settings: 1. Under Metadata -> Behaviour -> Write Metadata, I checked two additional boxes, face markings and GPS coordinates (all others were already checked before). 2. I checked Metadata -> Side Car Files -> compatibility with commercial programs, but I UNCHECKED again, after the info box appeared Then, I saved. After this, digikam told me that I selected a new folder for the database (which was not true) and asked me whether to copy or start over. I selected copy but it failed. With the other option digikam started completely fresh. So, I closed it. The file digikam4.db was gone in my database folder. Fortunately, digikam has made a copy of the database, so I copied and renamed it to digikam.db. After restarting, It showed my photos and a welcome message. Since then (roughly 60 minutes ago) digikam is indexing everything again and is now at 25%... OBSERVED RESULT See above. EXPECTED RESULT Keep database as is. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 6.8.1-arch1-1 (64-bit) / 6.0.2 (available in About System) KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION I can only access my backups in a couple of days I try to reproduce completely because I'm not at home right now.
You mean that after changing metadata settings, the sqlite database file have been dropped from your disk. This is very strange, i never seen this behavior in the past...
The file "digikam4.db" was gone, but a file called "digikam4.db-backup-2024-03-24T18:04:56" was there instead.
You have to rename the backup file to digikam4.db. Then you don't have to scan everything again. Maik
That's what I did, digkam started the scanning automatically.
This means you have set a new location for your database, otherwise it would use the file. Check the database settings to see if the path is still correct. Maik
It is still the same and I did not touch it.
Created attachment 167711 [details] digikam startup log (after bug happened)
Please see attached log: digikam.database: Creating new Location "/$USER/Bilder/Fotos" uuid "volumeid:?uuid=27ea6369-b602-469f-b7e7-XXXXXXXXXXX&fileuuid=40d34373-bac4-4760-bfca-XXXXXXXXXXX" Might it be some issue with the UUID? I migrated to a new laptop several weeks ago. However, it's strange that it appears now.
Git commit dcb3949d95ada9184da50aef5b88488985497c9e by Maik Qualmann. Committed on 24/03/2024 at 18:56. Pushed by mqualmann into branch 'master'. fix logic if the WAL mode changes, only check for changes to the database FIXED-IN: 8.4.0 M +1 -1 NEWS M +3 -4 core/libs/album/manager/albummanager_database.cpp https://invent.kde.org/graphics/digikam/-/commit/dcb3949d95ada9184da50aef5b88488985497c9e
Your log shows that after switching to another laptop, your collection settings are no longer completely valid, the UUID of the partition has changed. We have recently started using a new file UUID in the collection, which is why the collection can also be found after the change. You should still update the collections. Use the "update" function in the digikam settings under Collections (round circle icon) behind the collection. Normally you can simply adopt all the settings in the dialogs that arise. Maik
OK, I did this, but digikam is still continuing to perform a full scan for new entries. I assume it's save to continue to use the backup database or is there anything I need to check?
Certainly the UUID of the disk partition is not the same than original disk. In the Setup Collection, you have a button to adjust the UUID of a path managed by the database . https://docs.digikam.org/en/setup_application/collections_settings.html Gilles Caulier
I finally found some time to have another look and I can easily reproduce the bug with a backup. As per the discussion, it is because of the changed UUID and should be fixed in the next version, but did you also investigate why it happens after checking the two boxes in the settings? If needed, I can provide more info. I also made a PDF with some screenshots.
Created attachment 169579 [details] Screenshots