[Digikam-devel] [Bug 255478] digikam database tables only grow in size and get never cleaned

Marcel Wiesweg marcel.wiesweg at gmx.de
Mon Nov 15 09:01:59 GMT 2010


https://bugs.kde.org/show_bug.cgi?id=255478





--- Comment #11 from Marcel Wiesweg <marcel wiesweg gmx de>  2010-11-15 10:01:57 ---

> 167837||bla.jpg|3|1|2008-12-31T19:15:31|303900|5e5f380714166b45f9f8379a50433e5f 
> 167902|5690|bla.jpg|1|1|2008-12-31T19:15:31|303900|5e5f380714166b45f9f8379a50433e5f 
> 
> 
> It seems like the entry has not been updated, although it should be, right?
> Because otherwise the same image has a different ID now, I guess this does
> matter, right?

This is all right, the process is like this:
A new file is found, added to the database and the basic parameters (like the
hash) scanned. Then, the scanner sees that there exists an old entry with the
same hash/file size, and decides, instead of rescanning everything, just to
copy the information from that old file.

I'm not sure about the thumbnails problem, but it could be related to the fact
that thumbnails are referenced by file path additionally to hash.
If there is a filename a.jpg with a hash h_a and the thumbnail shown is of file
b.jpg with hash h_b, we'd need to find out
- which thumbnail images are referenced by h_a and h_b
- which thumbnail images are referenced by a.jpg and b.jpg
- is there a mismatch, like a.jpg, b.jpg and h_b point to the same thumbnail
while h_a does not point to anything?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Digikam-devel mailing list