Bug 255478

Thanks Roman...

Gilles Caulier

I think one idea not to delete this immediately is for the case that you restore a photo from the trash. But a manual action is a good idea. Also to remove generated fingerprints ;)

(In reply to comment #2)

> I think one idea not to delete this immediately is for the case that you
> restore a photo from the trash.

This was my first thought, I assumed you implemented it this way just to allow this.

> But a manual action is a good idea. Also to
> remove generated fingerprints

Or using a timestamp and remove aged (adjustable?) entries automatically, similar to the expire feature e.g. for mail folders in KMail.

Yes, currently it stays there for the case of restoration/copying again. This speeds up the processing then. But I agree with Roman to add a time expire feature. That would be great.

Idea and code is there for two years - CollectionScanner::checkDeleteRemoved() etc.
I have the impression though that there is a bug and the cleanup is never triggered ;-)

Marcel, the problem seems to be the following line:

http://lxr.kde.org/source/extragear/graphics/digikam/libs/database/collectionscanner.cpp#270

I guess this can not work. The passed in albumID list will not contain albums that have been deleted, right?
So we either need to change the query in void AlbumDB::deleteRemovedItems(QList<int> albumIds):

SqlQuery query = d->db->prepareQuery( QString("DELETE FROM Images WHERE status=? AND (album=? or album IS NULL);") );

or use the version without the parameter:
void AlbumDB::deleteRemovedItems()

This seems to work for me.

Andi

Marcel,

I guess the 
AlbumDB::deleteRemovedItems(QList<int> albumIds)
method will never work here, because when an image is delete, the album id is always NULL, so the query in this method can never clean up the database!

Andi

Marcel, 

there seems to be another problem: When I delete an album, and recreate it (move it back from the trash or the other location I moved it in to), I can see two entries for my images:

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 could explain my problems with thumbnails, sometimes a wrong thumbnail is displayed for restored images, and I can not fix it, only by removing the entry from the thumbnails-database.


Andi

Marcel,

I CC'd you, just in case you don't read this .... :-)

Andi

(In reply to comment #8)

> This could explain my problems with thumbnails, sometimes a wrong thumbnail is
> displayed for restored images, ...

I can reproduce this one as well, but I didn't know those problems are probably related, so I wanted to do some more testing before writing a bug report.

> 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?

SVN commit 1197260 by mwiesweg:

No sense in passing album ids to delete removed entries.
Andi, I think you tested this? Then we can close the bug.

CCBUG: 255478

 M  +3 -0      albumdb.cpp  
 M  +0 -6      albumdb.h  
 M  +1 -1      collectionscanner.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1197260

Yes I tested it and it worked fine, I will close the bug now.

A positive side effect (at least with sqlite) is that now the AlbumUI is much more responsible and thumbnails are loaded way faster, sure, my "images" table is only 12% of its original size now :-)
Maybe this fix will also solve some problems were people describe slowdowns in loading and using digiKam.

Since digiKam 5.6.0, we have a database maintenance tool to check integrity and clean tables.