Version: 2.1.0 (using KDE 4.7.0) OS: Linux After launching or changing album/collection digikam is a long time unresponsive without any indication what it is doing. example: I have under my albums ARCHIEF (23000) and GALLERY (17000). If I worked in ARCHIEF and I go to GALLERY, I make coffee, wash the dishes or take a shower because it becomes for minutes unusable. The same happens when you start with include album subtree deselected and then select it. I guess it is reading all thumbnails into memory. In my opinion it should be no problem to do that in realtime if the user scrolls. The way it is handled now is a real pain with large db. Reproducible: Always Steps to Reproduce: start digikam with large db include subdirs in view Actual Results: wait wait wait Expected Results: working right away
digikam/SQlite is able to handle large collection - with subtrees included, I select the root album, digikam needs a few seconds to list all 38000 images, scrolling is smooth, right side bar tag filters take about 500 ms (some noticeable delay, but less than a second). The large delays you describe give plenty of time to debug. Is CPU used? Which process is using CPU? Is the harddisk busy? What about memory usage, can you rule out that the system is out of memory and swapping? I recommend the KDE system monitor for all this information.
(In reply to comment #1) > digikam/SQlite is able to handle large collection - with subtrees included, I > select the root album, digikam needs a few seconds to list all 38000 images, > scrolling is smooth, right side bar tag filters take about 500 ms (some > noticeable delay, but less than a second). > > The large delays you describe give plenty of time to debug. Is CPU used? Which > process is using CPU? Is the harddisk busy? What about memory usage, can you > rule out that the system is out of memory and swapping? I recommend the KDE > system monitor for all this information. clicking on ARCHIEF makes digikam almost dead for 90 seconds, I watched the processes. CPU never >17%, memory constant 900MB/ 3,6GB, swap constant 64MB / 6GB I do not know how to measure diskactivity. This looks to support my first guess, reading all thumbs in memory. Rinus
Rinus, It still reproducible using last digiKam 4.2.0 ? Gilles Caulier
*** Bug 317606 has been marked as a duplicate of this bug. ***
*** Bug 300293 has been marked as a duplicate of this bug. ***
I have the same problem, i'm currently using version 4.2.0. I have a pretty large collection (about 250k images) and it takes more than 10 minutes to show the user interface. As I can see in the welcome screen, it takes a long time scaning albums and reading database. Is it possible to do run these tasks at background?
*** Bug 339916 has been marked as a duplicate of this bug. ***
I'm getting this bug, but i have a SMALL collection, by any professional photographers standard, only 350gigs. digikam is stalling for over an hour for me on startup!
This file still valid using last digiKam 5.0.0 ? Gilles Caulier
Git commit 27a7e771060fa8f6d40461b9444bb4496487f102 by Gilles Caulier. Committed on 17/07/2016 at 15:13. Pushed by cgilles into branch 'master'. Restore broken splashscreen animation while database process at startup. Related: bug 320359 M +20 -13 libs/widgets/common/dsplashscreen.cpp http://commits.kde.org/digikam/27a7e771060fa8f6d40461b9444bb4496487f102
Git commit 4047edd1532b129fe895a8c4b0f810adc92d2f7f by Gilles Caulier. Committed on 18/07/2016 at 12:48. Pushed by cgilles into branch 'master'. Improve digiKam startup time : ------------------------------ - remove splashscreen from ScanController. Always use a progress dialog instead in all cases. - We will always require a progress dialog at first init to scan albums. All details are given in dialog about which album is scanned and how many items still in the queue to process. - The splashscreen always arrive after the progress dialog. Splash show final stage to init GUI - When GUI is displayed, always start a delayed find new item process through progress manager. This is done in background. Progress info is given in progress manager as well. While scan for new item is running in a separated thread, user can start to work with GUI, even if all items are not yet catalogued in database. Related: bug 320359 FIXED-IN: 5.1.0 M +18 -29 app/main/digikamapp.cpp M +9 -42 libs/database/utils/scancontroller.cpp M +2 -3 libs/database/utils/scancontroller.h M +4 -2 utilities/maintenance/maintenancetool.h http://commits.kde.org/digikam/4047edd1532b129fe895a8c4b0f810adc92d2f7f
Git commit 4f270e01d50f31a4a3990aa9b0ad12629374fb35 by Gilles Caulier. Committed on 19/07/2016 at 19:34. Pushed by cgilles into branch 'master'. restore older scan for new items at startup option Related: bug 320359 M +6 -2 app/main/digikamapp.cpp M +2 -1 libs/settings/applicationsettings.cpp M +3 -0 libs/settings/applicationsettings.h M +10 -0 libs/settings/applicationsettings_miscs.cpp M +3 -0 libs/settings/applicationsettings_p.cpp M +1 -0 libs/settings/applicationsettings_p.h M +7 -0 utilities/setup/setupmisc.cpp http://commits.kde.org/digikam/4f270e01d50f31a4a3990aa9b0ad12629374fb35