Bug 294835 - Albums are listed with (0) photos, but Database Statistics shows correct numbers of photos
Summary: Albums are listed with (0) photos, but Database Statistics shows correct numb...
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Albums (show other bugs)
Version: 2.6.0
Platform: MacPorts macOS
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-26 01:17 UTC by tim
Modified: 2017-07-25 19:32 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 5.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2012-02-26 01:17:29 UTC
Version:           2.6.0 (using KDE 4.8.0) 
OS:                OS X

On the first run of Digikam, starting fresh with no database, Digikam crashes while scanning the first collection added.
Afterwards, the directory structure of the collection is shown properly in album view, but the contents are all listed as (0).  Looking at Help>Database Statics, the images are counted correctly.
Adding another collection works without crashing, but the photos still don't show up in the albums.


Reproducible: Always

Steps to Reproduce:
Digikam was compiled from the source tarball with dependencies provided from macports, except for marble source which came from the marble site.
I've uninstalled and recompiled Digikam and it happened the same way each time. 

Actual Results:  
See description

Expected Results:  
The photos should be visible in the albums.
Comment 1 caulier.gilles 2012-02-26 21:52:17 UTC
Sound like a KIO Slave problem on your computer. It sound like a binary compatibility issue on your computer

Gilles Caulier
Comment 2 Marcel Wiesweg 2012-02-27 18:07:28 UTC
You could also provide a backtrace from when digikam crashes in the first place - it shouldnt crash
Comment 3 tim 2012-02-27 23:45:30 UTC
DrKonqi starts automatically on the crash, but seems to get stuck for
hours or even overnight so I've never managed to get a backtrace in
osx.
Also, I found that the photos show up when the same database is used
by digikam 2.1.1 on ubuntu.

On 28 February 2012 05:07, Marcel Wiesweg <marcel.wiesweg@gmx.de> wrote:
> https://bugs.kde.org/show_bug.cgi?id=294835
>
>
>
>
>
> --- Comment #2 from Marcel Wiesweg <marcel wiesweg gmx de>  2012-02-27 18:07:28 ---
> You could also provide a backtrace from when digikam crashes in the first place
> - it shouldnt crash
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
Comment 4 caulier.gilles 2012-03-06 22:29:50 UTC
Git commit 38843d5cb19b3a064e62716f208a9e9ebb8b1b91 by Gilles Caulier.
Committed on 06/03/2012 at 23:16.
Pushed by cgilles into branch 'master'.

Remove digiKam kio-slave dependencies with digikamcore shared library.
By this commit, we limit external shared lib influence to kio-slave. For ex, why we need to link kio-slave with
Marble shared lib which is linked to digikamcore and can break binary compatibility when user update external packages.
This commit link digiKam kio-slave only with digikamdatabase. This will limit shared libs to load at kio-slave start, which
can be faster and prevent time-out under MACOSX and Windows.
Related: bug 224038

M  +2    -1    digikam/CMakeLists.txt
M  +2    -7    kioslave/CMakeLists.txt

http://commits.kde.org/digikam/38843d5cb19b3a064e62716f208a9e9ebb8b1b91
Comment 5 caulier.gilles 2013-12-04 16:51:18 UTC
Same case than bug  #224038 with same linking fix.

Closed as WORKFORME. Reopen if necessary

Gilles Caulier
Comment 6 caulier.gilles 2017-07-25 19:32:38 UTC
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.