Bug 156847 - Missing thumbnails in album overview
Summary: Missing thumbnails in album overview
Alias: None
Product: digikam
Classification: Unclassified
Component: Thumbs-Album (show other bugs)
Version: 2.9.0
Platform: openSUSE RPMs Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2008-01-28 13:53 UTC by Unknown
Modified: 2022-01-21 14:46 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 7.6.0

Filters LED in action (185.40 KB, image/png)
2008-02-01 13:29 UTC, caulier.gilles

Note You need to log in before you can comment on or make changes to this bug.
Description Unknown 2008-01-28 13:53:15 UTC
Version:            (using KDE 3.5.8)
Installed from:    SuSE RPMs

After updating to version 0.9.3 there are suddenly missing thumbnails.

All photos and database entries are present, but some pics are not shown in the thumbnail overview (some albums are comletely empty, in some albums there are only a few photos missing, I can't determine, what's the criteria for not showing the thumbs). If I downgrade the version to 0.9.2 everythings works fine again, a reinstall of the upgrade to version 0.9.3 let the the same photos disappear again.

For batch processes or the album preview the missing photos are considered, this affects only the thumb overview of an album. Recreating the thumbs takes no effect.

For me it looks like a displaying bug, database or files are not affected.

At the moment only a downgrade to version 0.9.2 solves the problem for me.
Comment 1 caulier.gilles 2008-01-30 06:19:30 UTC

Yes, same problem here when i have work on my RAW pictures taken during Christmas hollidays. Sometimes i have forget to reset icon view filter.

Perhaps we need something to ping user about active filter.

I'm open to all idea...

Gilles Caulier
Comment 2 Arnd Baecker 2008-01-30 08:12:19 UTC
Some replies of Gerhard only went to the mailing list:
Before #c1 he wrote:
> Just a wild guess (because this happens to me sometimes): 0.9.3 has a quick
> filter in the status bar. Sometimes I forget to clear it and a selection of
> thumbs shows up only.

and after #c1 he suggested as possible solution:
> What about flashing the active quick filter after one changes the view?

Now my commment: 
I don't like flashing too much.
Could we use maybe some color coding (e.g. red) as background
for the quick-filter?
And: the same  (=surprise that images appear lost?)
may happen if the Tags-filter is active.
Can one color the background of a side-bar TAB (again in red?)

(And yes, it also happens to me, so we should do something about it!)
Comment 3 caulier.gilles 2008-01-30 11:51:11 UTC
Arnd, Gerhard,

There is a KLed widget witch can be used to indicate than something is active in album icon view filter...


Comment 4 caulier.gilles 2008-01-30 14:08:09 UTC
SVN commit 768607 by cgilles:

digiKam from KDE3 branch: add small light in icon view filter to ping user if a filter is currently used
CCBUGS: 156847

 M  +30 -2     albumiconviewfilter.cpp  
 M  +5 -1      albumiconviewfilter.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=768607
Comment 5 caulier.gilles 2008-01-30 14:09:34 UTC
Arnd, Gerhard,

KLed added with revision #768607. Let's me hear if all is fine for you...

Comment 6 caulier.gilles 2008-01-30 14:14:08 UTC
SVN commit 768611 by cgilles:

backport commit #768607 from KDE3 branch
CCBUGS: 156847

 M  +29 -1     albumiconviewfilter.cpp  
 M  +5 -1      albumiconviewfilter.h  

WebSVN link: http://websvn.kde.org/?view=rev&revision=768611
Comment 7 caulier.gilles 2008-01-31 11:19:31 UTC
SVN commit 769049 by cgilles:

digiKam from KDE3 branch : Led from icon view filter : handle Tag Filters view (status and reset).
CCBUGS: 156847

 M  +3 -3      albumfolderview.cpp  
 M  +3 -3      albumfolderview.h  
 M  +23 -8     albumiconviewfilter.cpp  
 M  +10 -2     albumiconviewfilter.h  
 M  +6 -0      digikamapp.cpp  
 M  +1 -0      digikamapp.h  
 M  +14 -8     digikamview.cpp  
 M  +3 -2      digikamview.h  
 M  +2 -2      searchfolderview.cpp  
 M  +3 -3      searchfolderview.h  
 M  +31 -3     tagfilterview.cpp  
 M  +11 -4     tagfilterview.h  
 M  +3 -3      tagfolderview.cpp  
 M  +3 -3      tagfolderview.h  
 M  +2 -2      timelinefolderview.cpp  
 M  +2 -2      timelinefolderview.h  
 M  +2 -2      timelineview.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=769049
Comment 8 caulier.gilles 2008-02-01 13:20:14 UTC

I will be happy if you can test the current implementation from svn (future digiKam 0.9.4). I have introduced a new light indicator on status-bar to resume status of album icon view filtering.

If your problem is really relevant of filtering (using status bar filters introduced with 0.9.3 release), as i suspect because i have reproduce the same problem in my RAW workflow, well this indicator will help you very well.

I will attach a fresh screenshot witch show the new indicator in action.

Thanks in advance for your help...

Gilles Caulier

PS : To be abble to test current implementation from svn, please follow instructions from this url:


Comment 9 caulier.gilles 2008-02-01 13:29:33 UTC
Created attachment 23391 [details]
Filters LED in action
Comment 10 Unknown 2008-02-03 11:29:52 UTC

thanks for work. Unfortunately I'm not able to test the subversion implementation. 

But your screenshot gave me an idea to check all possible filters again: but neither I activated a tag filter (because I don't use the tag filters) nor I used one of the status bar filters. But there are missing thumbs anymore. Is it really a problem of the filters?
Comment 11 caulier.gilles 2008-02-03 12:31:08 UTC

All icon view filter behaviour is descripted to my blog, here :


Else, as digiKam developer, i can said than i cannot see any items disepear in my computer, excepted when i have used new icon filter of course (:=))))

I have no idea anymore. perhaps it's a packaging problem. I recommend you to try to recompile digiKam & co yourself to be sure.

You can join us into #digikam freenode.net IRC channel to ge some help...

Comment 12 Rob Walker 2008-03-11 21:50:12 UTC
I've seen something similar with digikam 0.9.3 - some of my folders were empty and some had less in them than they should have.  I don't use any of the filters.

Using the sqlite command line, I can see that the images are in the database, but don't show up in the folders or any searches.  I tried stepping around the digikam source with gdb.  I found that AlbumLister::matchesFilter (albumlister.cpp, line 274) was returning false for the missing images.  Closer inspection shows that the images had a rating of -1 returned by info->rating() and therefore "match" was set to false when checking the rating filter (greater than or equal to 0).  I wasn't explicitly enabling this filter, so I guess the 0 minimum rating is a default value.

I'm not sure how these images had a rating of -1.  I think I may have previously assigned a rating and then removed it when using an older version of digikam.

I used the sqlite command line to reset the rating of the missing pictures to 0 (like all my other pictures).  I can now see all the pictures.

Is this the cause of the missing items seen by the original submitter?

Rob Walker ( rob@tenfoot.org.uk )

Comment 13 Unknown 2008-03-11 22:09:55 UTC
Thanks Rob,

that is exactly the problem that I have. All my missing pictures in the overview seem to have the rating of -1 (as I determined with sqlite after your hint). I never used the rating, so the theory of removing the rating could cause this problem seems to be incorrect, but there must be a reason for being some ratings -1.
Comment 14 Arnd Baecker 2008-03-11 22:15:56 UTC
Rob, thanks a lot for the excellent analysis!
The origin of this was that there used to be a bug with associating
ratings by dragging the mouse left and right so that negative ratings or
ratings >5 were doable.
So now we have the problem that some images in the database
may have negative ratings.

Achim, maybe you can trick the system by doing doing a filter (or search?) with
rating <0. This could allow to find these images and you could
set them to rating 0. 

Comment 15 Arnd Baecker 2008-03-11 22:26:36 UTC
Marcel, most likely the best solution is to add some code
at startup, which corrects the database and (if necessary)
the exif info in the corresponding files. What do you think?
Comment 16 Unknown 2008-03-11 22:32:38 UTC

I set the ratings of value -1 bach to 0 using sqlite3 from command line. Now everything works fine with 0.9.3 :)

So we have to check how ratings < 0 were inserted into database and need an idea how to correct them for users without a manual command line database modification...
Comment 17 Arnd Baecker 2008-03-11 22:42:30 UTC

negative ratings were possible before this  bug
was fixed (with 0.9.3).

About the command you used for the database: maybe you could also post
it here, because it might be useful to others?

The general solution will be to perform an automatic check on startup
(maybe triggered only once, when an update to 0.9.3 is done).
Comment 18 Unknown 2008-03-11 23:00:22 UTC

sure, here is the used database modification:

achim@cs01:~/Pics> sqlite3 digikam.db
sqlite> update ImageProperties set value=0 where property='Rating' and value=-1;

Comment 19 Rob Walker 2008-03-11 23:08:12 UTC
It looks like a fix is already in the trunk branch: AlbumLister::matchesFilter includes a check for rating == -1 and sets it to 0 for use in the comparison.
Comment 20 Unknown 2008-03-12 09:31:26 UTC
Thanks for the info, Rob.

But: what is the better way for this problem? Add a check for rating -1 to the filter and keep the negative ratings (as it seeemed to be done in the main trunk) or set the negative ratings to 0 in the database on startup? 

I think the last one is the better way, because it prevents possible and similar problems in the future. 
Comment 21 Marcel Wiesweg 2008-03-16 17:20:29 UTC
For the KDE4 version, -1 is a valid value: sometime ago there was a discussion about the difference of "not rated" and "rating 0", with the result that there is a difference, so now -1 means "not rated" (although there is no UI to reset a rating of 0 to "not rated"). The effect is the -1 and 0 are treated mostly identical, but probably -1 can be searched for as "not rated".
Comment 22 Arnd Baecker 2008-03-16 22:58:06 UTC
Question: when you have the negative ratings, do these also appear
in the file itself (i.e. if you decided to store the rating in the exif)?
Comment 23 Rob Walker 2008-03-18 11:06:50 UTC
Exiftool doesn't report any tags called "Rating" or similar in any of the files that were affected.  

I only use digikam for managing my photos, so if that tag was set, then it would have come from digikam.  I don't usually sync the meta data back to the files, so the exif wouldn't have changed from when they were taken
Comment 24 Marcel Wiesweg 2008-03-19 23:03:11 UTC
I think I can confirm that digikam has a range check before writing the rating value in the images. This means that in the worst case, images will lack rating information.
This also means fixing the database is the way to go for 0.9.
Comment 25 Andi Clemens 2008-08-16 10:45:25 UTC
What about this report here? The original problem seems to be fixed, so I guess we can at least mark it as FIXED to reduce the digikam bug count...
Comment 26 caulier.gilles 2008-08-19 11:25:43 UTC

I'm not sure. look #24 comment from Marcel. in digiKam for KDE3, Rating info in database need to be fixed automatically by digiKam at startup.

Comment 27 caulier.gilles 2008-12-04 21:17:43 UTC

What's about to fix Rating values from database at startup (for KDE3)? 

Else, it's done with transition from KDE3 to KDE3 database schema ?

Gilles Caulier

Comment 28 Marcel Wiesweg 2008-12-04 22:36:01 UTC
For KDE4 every entry has a rating, with the default of -1 which means "not rated".

When the old database is upgraded, all assigned ratings of -1 (as produced by the bug described here) and of 0 are written as a rating of 0.

With the UI we cannot distinguish a rating of -1 from a rating of 0; if you ever rated an image and reset the value to 0, it will be 0, if you never rated it, it will be -1. This is the same if you did that with KDE3 or KDE4.
Comment 29 caulier.gilles 2008-12-05 13:02:40 UTC

what we can decide here ? This file can be considerated as fixed ?

Gilles Caulier
Comment 30 Marcel Wiesweg 2008-12-05 19:31:01 UTC
Fixed for KDE4, not fixed for KDE3 but a possible wontfix.
Comment 31 caulier.gilles 2008-12-05 20:14:09 UTC
Thanks Marcel,

Fixed for KDE4 is fine for me. 

I close this file now

Gilles Caulier
Comment 32 nkent 2013-01-27 21:22:28 UTC

OS:  Linux 3.4.11-2.16-desktop x86_64
System:  openSUSE 12.2 (x86_64)
KDE:  4.9.5 "release 3"

Version 2.9.0