Bug 182128

Summary:	duplicates search results don't refresh unless search re-run
Product:	[Applications] digikam	Reporter:	Michael Ploujnikov <ploujj>
Component:	Searches-Similarity	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	caulier.gilles, marcel.wiesweg
Priority:	NOR
Version:	0.10.0
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:	5.1.0
Sentry Crash Report:
Attachments:	screenshot #1 screenshot #2

Description Michael Ploujnikov 2009-01-28 04:35:33 UTC

Version:            (using KDE 4.1.4)
Compiler:          gcc (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) x86_64 platform
OS:                Linux
Installed from:    Fedora RPMs

Here is what I did to reproduce this problem along with my observations:
- I started digikam with a fresh digikam4.db
- quit digikam
- created two copies of some image in one of the albums with the 'cp' utility
- started digikam
- ran a duplicates search
- using digikam I deleted the manually created copies of a know image
- using digikam I deleted one similar duplicate image which I had in my album originally
- did Albums -> Refresh
- at this point the item counts are still as they were before I deleted the images (3 and 2 respectively). Also, duplicate reference images still appear in the search results although only one image shows up in the middle panel when I click on either reference image.
- then I restart digikam
- the duplicate search results still contain images with no existing duplicates as before and the item counts are wrong
- rerunning the search while one of the duplicate images is selected brings the search results to the inconsistent state described in bug 182043:
  - the search results still show the old duplicates and item counts.
  - clicking on the first duplicate reference image (whose duplicates should have been deleted) shows an unrelated set of duplicate images - screenshot #1.
  - clicking on another duplicate reference image (which was selected ruing the search and which should have it's duplicate removed) showed a blank middle panel - screenshot #2.


This is more general version of bug 182029 and I guess 182043.

I'm marking this as a bug since it seems very unintuitive from a user perspective, although technically it could be thought of as a feature (keeping search results as persistent as possible until the search is re-run).

Comment 1 Michael Ploujnikov 2009-01-28 04:38:11 UTC

Created attachment 30665 [details]
screenshot #1

Comment 2 Michael Ploujnikov 2009-01-28 04:38:28 UTC

Created attachment 30666 [details]
screenshot #2

Comment 3 Michael Ploujnikov 2009-01-28 04:38:52 UTC

*** Bug 182029 has been marked as a duplicate of this bug. ***

Comment 4 Marcel Wiesweg 2009-01-29 22:05:22 UTC

*** Bug 182043 has been marked as a duplicate of this bug. ***

Comment 5 Marcel Wiesweg 2009-01-29 22:09:22 UTC

Cause and workaround for this are simple: You need to re-create the duplicates search after you removed and added images.
The search is done once and then stored by image id. Entries from db can be removed, and new ones added, all this does not touch the duplicates search.
It would not be easy to sync the duplicates search everytime a picture is added / removed.
We could make this "offline" situation more clear. This affects only the duplicates search, all other searches search "online".

Comment 6 Andi Clemens 2009-01-29 22:14:37 UTC

But shouldn't removing images at least update the view? Isn't this possible and logical?
When new images are added, it might be obvious that you need to re-run the find duplicates search. But when I delete images (mainly in the duplicates search window), I definitely expect the number to be updated.

Comment 7 caulier.gilles 2009-01-29 22:16:34 UTC

>Cause and workaround for this are simple: You need to re-create the duplicates >search after you removed and added images. 

Perhaps a flag in DB can be used to see if collection is dirty (with images stats as how many images have been added ?). In this case, something can be done when duplicates search is selected by user to ask that duplicates search need to be updated.

Also, i'm not sure if haar matrix is recomputed automatically when new images are added to collection (by camera interface, or with Editor)

Gilles

Comment 8 Marcel Wiesweg 2009-01-30 22:35:15 UTC

No the haar matrix is not recomputed automatically. Haar matrix computation can be orders of size more expensive than just scanning, so this would really slow down things.

Comment 9 caulier.gilles 2011-12-14 16:35:03 UTC

Michael,

This file still valid using digiKam 2.x serie ?

Gilles Caulier

Comment 10 Michael Ploujnikov 2011-12-18 02:24:01 UTC

Sorry, I don't have time/ability to reproduce this at the moment.

Comment 11 caulier.gilles 2015-07-01 06:04:04 UTC

New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Comment 12 caulier.gilles 2016-07-15 19:03:19 UTC

With digiKam 5.0.0, this problem is not reproducible.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier