This problem occurs occurs at multiple spots. The first one is the maintenance dialog. When you start a duplicates search in this dialog and choose a similarity range of let's say 70-100%, the search starts. But when the search is finished and the duplicates view is in focus, the similarity range there is the default (90-100%). Thus, the range is not the range used for the created SAlbums. The second spot where the problem occurs is in the currently submitted duplicate albums refresh. If you restart Digikam, the similarity range is set to the default value of 90-100%. If you delete one image and a duplicates search is triggered, this range is taken. This is a problem, if the albums were previously created with another range since the result set is not consistent any more.
If i'm not too wrong, the similarity threshold must be saved in SAlbum in database, as property. We need to do the same for max threshold typically... Gilles Caulier
(In reply to caulier.gilles from comment #1) > If i'm not too wrong, the similarity threshold must be saved in SAlbum in > database, as property. We need to do the same for max threshold typically... > > Gilles Caulier Hey Gilles, this is done in fuzzy search where only one SAlbum is done. In fact, for fuzzy search, the recently used minimum and maximum values are also stored in the digikamrc. In duplicate search, saving the range in every search query can bloat the database size unnecessarily. Moreover, it would be necessary to ensure that for all duplicates searches, the range is equal. This is a fact currently. I think there is a better solution. The FuzzySearchView is a StateSavingObject. This ensures that on startup, the last values are loaded and on shutdown, the current are saved. But this is not sufficient in this context since the range used in the maintenance dialog should be automatically synced in the FindDuplicatesView. Here, I do not think that using StateSavingObject is sufficient. For recently used tags, the coredb automatically synchronises after every tag change, for example. I see two spots where one could set a hook. Independently from where you trigger duplicate search, you always will eventually call slotDone or slotCancel in DuplicatesFinder. I think slotDone is the best spot to save the least recently used range. The next spot is the FindDuplicatesView. In the constructor, the least recent range can be loaded instead of default values. But if you use the maintenance dialog after the FindDuplicatesView is instantiated, this would not help since the values are already set. Luckily, the finished search finally leads to a call of the slots albumDeleted, albumAdded or searchUpdated since they are connected to the AlbumManager. In these slots, the range could be updated to the least recent range. I do not think that accessing the digikamrc from different classes (DublicatesFinder, FindDuplicatesView and MaintenanceMgr) is a really good solution since it leads to much code. I thought about using the Settings table of the database since the access is straightforward. In fact, I also have a patch here... Just take a look
Created attachment 102389 [details] The proposed patch.
>I do not think that accessing the digikamrc from different classes >(DublicatesFinder, FindDuplicatesView and MaintenanceMgr) is a really good >solution since it leads to much code. It's not a problem. We have ApplicationSettings class singleton dedicated for that. https://cgit.kde.org/digikam.git/tree/libs/settings >I thought about using the Settings table >of the database since the access is straightforward. No this is not the right way to do... Gilles Caulier
(In reply to caulier.gilles from comment #4) > >I do not think that accessing the digikamrc from different classes > >(DublicatesFinder, FindDuplicatesView and MaintenanceMgr) is a really good > >solution since it leads to much code. > > It's not a problem. We have ApplicationSettings class singleton dedicated > for that. > > https://cgit.kde.org/digikam.git/tree/libs/settings > > > >I thought about using the Settings table > >of the database since the access is straightforward. > > No this is not the right way to do... > > Gilles Caulier Hey Gilles, many thanks for this hint. This makes it quite convenient to work with the configuration. I adopted my patch yesterday eve. Now, I save the last minimum and maximum similarity in the Duplicates Search View section of the digikamrc. I could have opened a new Section. But these configuration values are used only in the Duplicates Search View. So I don't want to open a new section only for those two values.
Created attachment 102404 [details] New variant of the patch. Last values are stored in the digikamrc. Don't be confused about the big count of changed lines. I adopted the indentation in the applicationsettings.
Git commit 4e25b2b3558e5e73853eabb4af7d48ee61b39c9f by Gilles Caulier. Committed on 23/11/2016 at 16:03. Pushed by cgilles into branch 'master'. apply patch #102404 from Mario Franck to save Similarity range values in digikamrc file FIXED-IN: 5.4.0 M +3 -1 NEWS M +106 -94 libs/settings/applicationsettings.cpp M +6 -0 libs/settings/applicationsettings.h M +21 -0 libs/settings/applicationsettings_miscs.cpp M +8 -0 libs/settings/applicationsettings_p.cpp M +6 -0 libs/settings/applicationsettings_p.h M +9 -2 utilities/fuzzysearch/findduplicatesview.cpp M +5 -0 utilities/maintenance/duplicatesfinder.cpp https://commits.kde.org/digikam/4e25b2b3558e5e73853eabb4af7d48ee61b39c9f