SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** After using digiKam for few times, I have extremely long boot time, the splash screen is blocked on "loading Albums". The animation of the three blue circles is not moving. STEPS TO REPRODUCE 1. Start to use digiKam, with new database. 2. use the "detect duplicates function 3. when the 100% is reached, the program does not respond, and the progress bar is blocked on 100% 4. upon forced kill and reboot the loading time is long, with no moving circles in the splashscreen animation 5. the time grows over time, and after several sessions it becomes as long as 5 or 10 minutes OBSERVED RESULT Around 1 or 2 minutes of loading time at startup EXPECTED RESULT few seconds of loading time at startup SOFTWARE/OS VERSIONS Linux/KDE Plasma: Mint 20.2 (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: 5.15.3 ADDITIONAL INFORMATION I have SQLlite database, with around 70'000 images
Hi and happy new year, Can you reproduce this problem with the AppImage linux bundle that we provide ? I recommend to test with 7.5.0 pre release file available here : https://files.kde.org/digikam/ Best regards Gilles Caulier
Maik, In the components listed with this report i can see that Linux Mint 20.2 package Qt 5.15.3. How it's possible as this version is not published in open source ? In Download Qt IO web site, there is no Qt 5.15.3 tarball : https://download.qt.io/official_releases/qt/5.15/ Gilles
Hmm, Linux Mint and such a current Qt version I can't imagine. We definitely need the log from the terminal with the Qt debug variable active, as described here: https://www.digikam.org/contribute/ Now it can take a while until the duplicate search is loaded if you have set the range too far and want to list thousands of duplicate items. For this reason we have limited the lower range to 40% (can be changed in the setup), which can still be too little for a large collection. Maik
Hi Maik, I think i know where Linux Mint take the Qt 5.15.3. It come from the KDE Qt LTS repository certainly. Look the version marked in this repository : https://invent.kde.org/qt/qt/qtbase/-/blob/kde/5.15/.qmake.conf#L9 I prepared a script to checkout this Qt 5.15 LTS code from this git repository. The goal is to use it with AppImage bundle. https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/3rdparty/ext_qt/5.15-LTS/kde-qt5-lts.sh For MXE and Macports, i created 2 reports in the respective project. Note : i don't know if this repository include yet the fix for Mysql compatibility. There is no filtered changelog in this repository, excepted the git log messages. Gilles
Maik, I take a closed look in next Mageia 9 rpms to see how Qt 5.15 source code is taken. Look in log file : http://sophie.zarb.org/rpms/966765c6dd33427e4294058a6828e7a8/changelog The code is taken from KDE5.15-LTS repository, we have plenty of "Sync with Qt KDE Collection patches". I currently compile this code now for the AppImage bundle. Until now it compile, but it take age, especially with QtWebEngine, as usual... Gilles
@Fabio digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
@Fabio, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
I have validated that this behavior is reproducible on Digikam 8.2 with a Windows 11 x64 installation, connecting to a network drive. Prior to performing the "Find Duplicates" step, the time to load albums was around 10seconds. Now, it never finishes, even after running for 10+ hours overnight.
Please try the pre-release digiKam-8.3.0 version from here: https://files.kde.org/digikam/ Maik