Version: 0.10.0-beta2 (using 4.1.1 (KDE 4.1.1), 4.1.1-12.fc9 Fedora) Compiler: gcc OS: Linux (x86_64) release 2.6.26 When loading Digikam for the first time, and therefore building the database, Digikam simply does not show any pictures. Console output, immediately after clicking one of the albums in the side pane, says: digikam(8704): Failed to list url: "El proceso para el protocolo digikamalbums terminó inesperadamente." "The process for digikamalbums protocol finished unexpectedly." Why?
Your image are properly backported to database. The failure come from kioslave which have been baddly installed on your system (not in KDE4 dir) If you have compiled digiKam yourself, try to use one of bootstrap script from digikam/project subfolder of source code tarball. These script tune env. variables before compilation. Gilles Caulier
I'm sorry but the files were installed correctly in /usr/lib64/kde4 as all other kioslaves, this is from the kde-unstable Fedora kde-redhat repo. I have neither the machine nor the desire nor the time to compile digikam from source, it will take more than a day and render the machine unusable for anything else while compiling, so I just downgraded to the 0.9.x series. You should consider handling this type of error better (it's very likely you're happily ignoring an error return value somewhere) and presenting the user with an error dialog, or at least an assert() so we gdb users can identify the problem quickly. Not everyone runs their stuff from a console to be able to identify what's wrong. I know that you'd rather debug with me a source-built version of digikam, but that's just unrealistic to ask from every user. I also know that you haven't packaged the package and that it's likely (but by no means definitively) a packaging bug.
When you say "When loading Digikam for the first time", does that imply the problem does only occur on the very first start and it is all right after restarting once?
I can confirm that the problem persists per secula seculorum. It's like the database is built (I can see it takes about a meg in disk) but the digikam album kioslave failed to provide a "directory listing" to digikam itself, every time I click on one of the albums.
> I know that you'd rather debug with me a source-built version of digikam, but > that's just unrealistic to ask from every user. As pointed out on the digikam homepage, 0.10-beta2 is "BETA code with many of new bugs not yet fixed", in particular, "DO NOT USE YET IN PRODUCTION". > I have neither the machine nor the desire nor the time to compile digikam from > source, it will take more than a day and render the machine unusable for > anything else while compiling, so I just downgraded to the 0.9.x series. And from the developer side it is not possible to chase a bug like this without further input. Moreover, 0.10-beta3 is out for a while, and most likely (according to the experience of other users), the particular issue you raise is already fixed there or in current svn. Because of this, I am marking this bug as invalid, but don't hesitate to re-open if you have additional information Best, Arnd
I will probably retest this when beta3 comes out in RPM form. In the meantime, digikam stable is equally not useful to me because the iPod export plugin simply corrupts the photo database intead of copying the photos. So how's that face recognition tagger plugin that I read about a while ago going?
This problem is relevant of digiKam KIO Slaves and all of these have been dropped in favor of a multi-threaded interface to query the database.