Created attachment 62193 [details] Screenshot showing the empty album view Version: 2.0.0 (using KDE 4.6.5) OS: Linux I just tested digiKam Version 2.0.0-rc. I compiled it from the sources on an up-to-date Archlinux. I first tried to launch digiKam with my existing DB. No image was displayed in the album view even if the folder tree showed up correctly on the left hand side. I then closed digiKam and deleted everything related to it in ~/.kde and I also removed it's SQLite DB files. When I re-started digiKam I did the setup and it scanned all my albums. The main window than appeared and the album are once again empty. I tried right-clicking on a album and I selected "Rebuild Thumbnails". I saw a dialog informing me of the progress and showing tiny thumbnails, but still no image is displayed. I also made sure that there are no active filter. I also tried browsing with the tags, but I get the exact same result. The database stats prove that digiKam did find images : digiKam version 2.0.0-rc Images: JP2: 1589 JPG: 22995 PNG: 67 RAW-CR2: 534 RAW-NEF: 149 TIFF: 13 total: 25347 : : Videos: 3GP: 1 AVI: 42 MOV: 83 total: 126 : : Total Items: 25473 Albums: 274 Tags: 213 Database backend: QSQLITE Reproducible: Always Steps to Reproduce: Build digikam Version 2.0.0-rc from source, install it in /usr/local/, fire it up and voila! Nothing appears in the main window where the thumbnails should show up. Actual Results: Nothing is shown in the Album view. Expected Results: I expected to see plenty of nice thumbnails. OS: Linux (x86_64) release 2.6.39-ARCH Compiler: gcc
Probably the ioslaves are not correctly installed or not found by the KDE runtime system.
Looks like you are right! Starting digiKam in a terminal I get the following output : $ digikam QSqlDatabasePrivate::removeDatabase: connection 'ConnectionTest' is still in use, all queries will cease to work. digikam(1884): couldn't create slave: "Unable to create io-slave: klauncher said: Unknown protocol 'digikamdates'. " digikam(1884)/digikam (core) Digikam::AlbumManager::slotDatesJobResult: Failed to list dates digikam(1884): couldn't create slave: "Unable to create io-slave: klauncher said: Unknown protocol 'digikamalbums'. " digikam(1884)/digikam (core) Digikam::ImageAlbumModel::slotResult: Failed to list url: "Could not start process Unable to create io-slave: klauncher said: Unknown protocol 'digikamalbums'. ." digikam(1884)/kdecore (trader) KServiceTypeTrader::defaultOffers: KServiceTypeTrader: serviceType "Digikam/ImagePlugin" not found So, where does digiKam look for it's ioslaves?
kbuildsycoca4 --noincremental kdeinit4 digikam may solve some problems, if you set some $LD_* variable do it before launching these 3 commands. Be warned that this may have some effect on already running kde applications
Thank you for the tip Francesco, but I already tried that. I had built digiKam without specifying a prefix and "make install" put it in /usr/local. I saw that the /usr/local/lib folder contained some sub-directories with KDE stuff. I still tried adding /usr/local/lib to LD_LIBRARY_PATH, but it didn't work. I guess that KDE expects to find some *.so in specific directories. I just tried recompiling from source while setting the prefix : cmake . -DCMAKE_INSTALL_PREFIX=/usr make -j2 But the compilation fails with : [ 37%] Built target libacquireimages make[2]: *** No rule to make target `/usr/local/lib/libksane.so', needed by `lib/kipiplugin_acquireimages.so'. Stop. make[1]: *** [extra/kipi-plugins/acquireimages/CMakeFiles/kipiplugin_acquireimages.dir/all] Error 2 make: *** [all] Error 2 This is a separate problem. The build instructions are fairly short. I'm Googling around to see how I'm supposed to build the sources before I submit another bug report ;) I was expecting the build process to be fairly straightforward...
the kio are in lib, the exact path is shown by: grep kio install_manifest.txt in the cmake build directory, try to run `kdeinit4` in a standalone shell it will show some debug info (remember to set the proper environment) I do generally uninstall system digikam to avoid confusion but should not be needed