Bug 448079 - Rebuilding thumbnails does not really rebuild thumbnails, no change in db size
Summary: Rebuilding thumbnails does not really rebuild thumbnails, no change in db size
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Maintenance-Thumbs (other bugs)
Version First Reported In: 7.4.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-07 17:58 UTC by testvonmir
Modified: 2022-01-09 10:01 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 7.5.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description testvonmir 2022-01-07 17:58:33 UTC
SUMMARY
***
When running Rebuild thumbnails from maintenance window, the thumbnails are not actually generated from the image data. At least the database size stayed completly the same when rebuilding process was started.
***


STEPS TO REPRODUCE
1. Run Rebuild Thumbnails from Maintenance window
2. Observe thumbnail database file size (thumbnails-digikam.db) 

OBSERVED RESULT
Thumbnails are rebuilt (all thumbnails in digikam windows disappear), but file size of database does not change

EXPECTED RESULT
Complete rebuild of thumbnails after purging the database (file size ~0)

SOFTWARE/OS VERSIONS
Windows 10 Pro, 21H2, 19044.1415

ADDITIONAL INFORMATION
After experimenting with the face detection and recognition, I wanted to clean up my photo collection to make sure I did not mess up any images or thumbnails in the process. When doing the process described above, I noticed that result.
Additionally, after changing the option for high-res thumbnails (Settings -> Views -> Use large thumbnail size for high screen resolution), the database file size stayed the same, where I would have expected a file size about 4 times larger.
Deleting the database file while digikam was closed and letting digikam rebuild the file led to a notably larger database as expected. Digikam seemed to hang in between, but I am not really sure about that. Restarting digikam continued the process anyway.
I am therefore not sure, if my thumbnail database was corrupted (should be okay now, since I deleted it and let it build again from scratch) or if this is a bug. I tested it only once, since it is a very time consuming process (the images are on a network drive from where the access is not the fastest...).
Comment 1 Maik Qualmann 2022-01-07 18:04:46 UTC
It is completely normal. The thumbnails will be recreated and stored in the database. It is common that this does not reduce the size of a database because of performance. In the maintenance tool you can clean up the database of old entries and run a vacuum. Now the database is also getting smaller. We have already improved the process in digiKam-7.5.0 and fixed bugs. 

Maik
Comment 2 testvonmir 2022-01-09 09:28:46 UTC
Okay, thanks for explaining.
But when rebuilding thumbs after switching to high-res thumbs, I should notice an increase in data base size (as it also did when after it rebuilt the thumbs when I deleted the database file), correct?
This did not work for me - is it already fixed, too or can't it be reproduced and was just a "temporary glitch" for me?

Regards
Comment 3 Maik Qualmann 2022-01-09 10:01:44 UTC
Normally, thumbnails are stored in the database with 256px. If you activate high-resolution thumbnails in the digiKam setup, thumbnails are recalculated with 512px, the database should be larger, depending on how big the vacuum of the DB is. If you have a 4K desktop resolution, thumbnails can even be created with 1024px.

Maik