Version: 1.0.0 beta2 (using KDE 4.2.2) Compiler: gcc 4.3.3 (Ubuntu 4.3.3-5ubuntu4) Target: x86_64-linux-gnu OS: Linux Installed from: Compiled From Sources Hello, in Ubuntu 9.04 amd64, own compiled digiKam 1.0.0 beta2. I am experiencing 100 % CPU use with digiKam. At the moment, this seems to start on many actions (switching to another album, changing a file in the album hierarchy using file manager, adding a tag, etc.). I have a dual core, but just one core is fully utilised - hence the system is still responsive and otherwise digiKam works fine and does not crash. gdb does not show anything, valrind output on copy&paste of file by nautilus (in Gnome) within Album's directory managed by digiKam is attached below. What other debugging info would be helpful? (Recompiling with debug? Which packages of Qt/KDE?)
-compile digiKam with debug info (look README for details) -start digiKAm from a console. Look error messages. -100% CPU => look digiKam kio-slave process. - Go to Help/components Info and copy & paste here all info. Gilles Caulier
Created attachment 35483 [details] Valgrind output for file copy and paste operation. I will recompile digiKam with debugging info and provide more details soon.
Running digiKam compiled with debug/debugfull did not reveal any new information. However, removing the digikam4.db and thumbnails-digikam.db solved the problem. A slightly off-topic question: do I loose any information when I rebuild the database from scratch by scanning all images? (Before doing so, I had checked all "save as metadata" options in digiKam settings and synchronised the database with images. I do not tag raw images, only JPEGs.) As far as I can say, it looks that nothing was lost. But due to the number of images I cannot really check completely. Thanks for info.
In theory, nothing will be lost with JPEG. Can you reproduce the problem now, with new database files generated ? Gilles Caulier
Maybe the problem is the new thumbnails-db? I have the same issue, digiKam is way slower now. Sqlite doesn't seem to be a good choice here, we are already thinking of new backends to use.
I have tried to run digiKam with: 1) old_database + new_thumbnail_db 2) new_database + old_thumbnail_db The former lead to 100 % CPU usage, the latter not. Hence I assume it is related to the digikam4.db. Also, I have noticed the old_database size of 78 MB is way bigger then 18 MB of the new_database. Not sure how come: some redundancy caused by heavy use in the past (lots of mass import, changes to tag names, moving in hierarchy, syncing)? If I recall, the old_database was created by digiKam 0.10.0 originally.
Milan: The different db size maybe because you had image fingerprints generated for your old db. To find out the reason of your CPU load you can try profiling with callgrind. You start digikam under "valgrind --tool=callgrind --instr-atstart=no", prepare your testcase. From a different console type "callgrind_control -i on" to start profiling and execute your testcase (slow!). Directly afterwards terminate digikam with "callgrind_control -k" and you have your callgrind output file generated.
BTW, dispwin does more things at once, basic usage is: $ dispwin -d and read the output, near the "-d" switch within the help it should also list available X screens and their resolutions. $ dispwin -d 1 -I /path/to/profile/sRGB.icm loads the VCGT tag to video card (in case of synthetic profiles, nothing happens), copies the profile to ~/.local/share/color/icc/devices/display/sRGB.icm, and sets _ICC_PROFILE property. However, this is not permanent - on next restart, the video card is set to linear and the _ICC_PROFILE property is not set automatically by the X.org and the user must run $ dispwin -L which will locate the installed profile on the basis of attached display and set it to _ICC_PROFILE. Note that dispwin may have problems with nVidia TwinView, while it should work with Xinerama. xicc is unusable for those preparing their own display profiles, since it cannot load the vcgt tag (which is important to get the display to a calibrated state), it only sets _ICC_PROFILE. However, for testing purposes, xicc is way easier to use.
Oops, comment #18 should have been posted to bug 197817. https://bugs.kde.org/show_bug.cgi?id=197817 Sorry.
I have not been able to reproduce the original bug anymore since the rebuilding the databases, so I would propose to close it.
Ok, thanks for the feedback. I close this file now. Gilles Caulier