Bug 156847

Gerhard,

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

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!)

Arnd, Gerhard,

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

http://api.kde.org/3.5-api/kdelibs-apidocs/kdeui/html/classKLed.html

Gilles

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

Arnd, Gerhard,

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

Gilles

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

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

Achim,

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:

http://www.digikam.org/?q=download/svn

Created attachment 23391 [details]
Filters LED in action

Gilles,

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?

Achim,

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

http://www.digikam.org/?q=node/296

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...

Gilles

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 )

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.

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. 

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?

Arnd,

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...

Achim, 

negative ratings were possible before this  bug
  http://bugs.kde.org/show_bug.cgi?id=151357
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).

Arnd,

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;

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.

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. 

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".

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)?

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

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.

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...

Andi,

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.

Gilles

Marcel,

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

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.

Marcel, 

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

Gilles Caulier

Fixed for KDE4, not fixed for KDE3 but a possible wontfix.

Thanks Marcel,

Fixed for KDE4 is fine for me. 

I close this file now

Gilles Caulier

STILL HAPPENS!

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

digiKam
Version 2.9.0