| Summary: | Very slow start | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jānis Elmeris <janise> |
| Component: | Searches-Similarity | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arne, caulier.gilles, mario.frank, metzpinguin |
| Priority: | NOR | ||
| Version: | 5.6.0 | ||
| Target Milestone: | --- | ||
| Platform: | Mint (Ubuntu based) | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 5.6.0 | |
| Sentry Crash Report: | |||
|
Description
Jānis Elmeris
2017-04-10 14:41:10 UTC
Very strange, QCollator should not be called here. We sort the column with the result counter at the start. If digiKam is started and you sort the reference Image column from the duplicates search, does it take long? Maik If I go to tha "Fuzzy" tab, there is nothing in "Duplicates" tab, at first. Then I click "Find duplicates" and immediately get a "Process id done" message, and no duplicates found. So, I cannot really sort them either. If I click on the image column header, the sorting icon (the small triangle) gets switched or toggled accordingly and without any visible delay. Git commit 29ee560d14ffb22d37b85a55f9d666a116097652 by Mario Frank. Committed on 11/04/2017 at 12:16. Pushed by mfrank into branch 'master'. Ignore the signal that a search album was added until the find duplicates view is active. This is already done in fuzzy search view. Otherwise, the automated sorting of entries is triggered which is not necessary. Hopefully, this solves bug id 378625. M +17 -1 utilities/fuzzysearch/findduplicatesview.cpp M +1 -0 utilities/fuzzysearch/findduplicatesview.h M +1 -0 utilities/fuzzysearch/fuzzysearchview.cpp https://commits.kde.org/digikam/29ee560d14ffb22d37b85a55f9d666a116097652 I hope that my adoptions solve the problem. Sadly, I cannot reproduce it - neither with 5.5, nor with 5.6 or current master branch. The next AppImage will contain the adoptions. Unfortunately, I won't be able to confirm if this has fixed the issue or not, as today there is no more delay also with the version 5.5. Maybe opening the duplicate search and issuing the find command cleared something. I do not remember if I really did not launch digiKam after that. The new AppImage bundle 64 and 32 bits are now available in GDrive : https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier new 5.6.0 pre-release as bundle is available here : https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Please check if this problem still reproducible with these versions. Gilles Caulier I had the same problem and the newest appimages fixes it (for me at least). Release 5.5: >30 min startup 5.6 pre-release: <1min startup I hope this feedback helps and thanks for all the work! Thanks for the feedback. I close this file now. Gilles Caulier Git commit d4ca2f4cd3ac5f0776f1159bd54aff5c9fe601ea by Gilles Caulier. Committed on 22/05/2017 at 12:40. Pushed by cgilles into branch 'master'. patch from Mario Frank to reduce the time latency on startup by wiring the albumsmanager to the find duplicates view after all albums were loaded. M +18 -10 utilities/fuzzysearch/findduplicatesview.cpp M +1 -0 utilities/fuzzysearch/findduplicatesview.h https://commits.kde.org/digikam/d4ca2f4cd3ac5f0776f1159bd54aff5c9fe601ea |