Version: 0.9.4-beta4 (using KDE 3.5.9)
Installed from: Gentoo Packages
I have a quite large photo collection and everytime I start digiKam, it stays at the splash screen (reading database) for several minutes without showing and progress. A "strace" shows that it is going through all the directoriesof my album, but extremely slow.
But as soon as I stop "famd", even during the startup phase, digiKam immediately starts to come up within few seconds!
So I guess that there is some incompatibility between digiKam and famd!? (I use fam-2.7.0)
Without famd -> startup within less than 10 seconds.
With famd -> startup takes several minutes.
Is that a known problem?
Digikam is setting up a KDirWatch to monitor the directories it manages for added/removed files while it is running. That's all digikam is doing: Add a directory to the KDirWatch object.
KDirWatch from kdelibs can use different methods to watch files, one of them famd.
There has been a bug report about too many open file descriptors when using IIRC the inotify method, but I am not aware of a famd problem. Digikam is pushing the boundaries of dir watching by creating many watches, but from within digikam we cannot do too much about it. Kdelibs decides to use fam, and obviously this takes so much time. You can verify this by commenting out the three lines in digikam/albummanger.cpp containing "d->dirWatch->addDir"
great, thank you for that hint!
A strace of the digikam confirmed that it was the KDirWatch that was setting up many connections to famd and then blocks for a long time. It seems that kdelibs are able to use other methods automatically if the necessary tools are installed in the system, but don't complain in any way if not.
I installed the packages "inotify-tools" and "dnotify" and now the startup of digiKam is like "instant-on" :-)
IMHO you can set the state of this bug to "RESOLVED".
Just to be sure, What are debug messages printed on the console by digiKam, just after the startup ?
I now already have re-compiled kdelibs without fam support, so digiKam now only prints out one line with "Found dcraw version: 8.83" - nothing else, sorry.
But I remember that before (with fam) I saw strace output like "KDirWatch setup FAM (Req <x>) for <some_directory> ...", with "x" counting up to some high number (about 256) until it blocked. ("ulimit -n" gives 1024 on my system, so it shouldn't be a out-of-filehandle situation?).
What's news with this report ?
there is nothing new from my side.
As I already said (see comment #2), it already works fine for me and I had no reason to do any further investigation.