Bug 160564

Yes, 

sometimes, i can reproduce the problem, but not everytime.

This is the same for you ?

Gilles Caulier

Well, I have tried three or four times and it happened always, but I can't discard that it will work eventually.

Marcel,

I suspect than the problem come from MetadataHub::write(ImageInfo*, WriteMode) which do not ping AlbumManager::scanTAlbums() when all tags are assigned/unassigned to images.

AlbumManager::scanTAlbums() will emit signalTAlbumsDirty() which contain a map of count of items. this map is used by all tags folder view. This signal is never emitted in this case...

Gilles Caulier

I can confirm this and it seems to happen only when all instances of the tags are removed. I created a new database for this test. Example:

1. only one tag exists to keep testing simple
2. only one folder exists to keep testing simple (9 images)
3. select all images in the folder, assign the tag
4. totals are getting updated correctly
5. select not all images (8 images), remove tag
6. totals are getting updated correctly
7. now select the one remaining image
8. remove tag
9. totals are not updated
10. select all images again, assign
11. totals are getting updated correctly
12. select all images, remove tag
13. totals are not updated...

Playing around with GDB, I found out that in TagFolderView::slotRefresh (line 1016) the Map doesn't contain the right values. In my example the tag has the ID 2. If I remove the tag from all images, the data of the map contains a strange integer value (1635373), if I remove the tag only from 8 images, data field of the map contains a '1', which is correct.
Somehow removing the last instance of a tag-image-relationship (which happens on removing all tags for example) sets a wrong data field in the tagsStatMap.
But I don't really know what to do about it. Went through all Hub functions, but I can't see anything strange.

Gilles, Marcel, any idea?

Created attachment 26459 [details]
patch for displaying the error

This one is really killing me. For the last 3 weeks I'm working on this, but I
have no clue what is going wrong.
I spent 3 hours stepping through the source with GDB but now I have no idea
where to look anymore.
Something is going wrong when the KIO::Job is executed.
My first thought was that when scanTAlbums() is executed, it will not notice
the tag anymore because it has no association with any image in the ImageTags
table. But this is not the case, the tag is still read.

If you apply the patch you will see that there is actually something going on.
The tag count is initialized with a random number, sometimes it even works
correct. But most of the time the counter reads something like 12343432...

The KDE4 version seems to avoid updating these counters completely, so right
now I'm only able to test it with the KDE3 branch.

Gilles, Marcel, maybe you have any idea why the counter is not initialized
correctly? Use this patch to see what is going on, maybe it will help.

Created attachment 26460 [details]
the right patch this time

oops I uploaded the wrong patch...

If above patch is not applied, the reason for not updating the counter can be found in here for example:
http://lxr.kde.org/source/extragear/graphics/digikam/digikam/tagfilterview.cpp#137

m_album will be empty if all tag instances are removed from images and so the refresh is not done. With the patch applied it seems to work and you get the uninitialized count valued displayed.

Created attachment 26579 [details]
fixes the issue

Finally I found a solution. The problem can be found in the kioslave. We only
fill the tagsMap with the tags assigned to images and count those, but the
other existing tags in the database are ignored.
This patch will initialize the map with all tags found in database and set the
count to zero.

I just recognize that there is some code left from an old test I made in the kioslave. I will not upload a new patch, but on commit those lines will be removed...

Andi

In KDE4, we have currently disabled the scan method in dio.cpp so I can't test / apply a patch there. Tag counts are only done on startup right now or when settings changed.

Created attachment 26834 [details]
counter fix for tags and albums

I just recognized that the described bug is also true for normal album folders.
This patch fixes both issues.

Andi,

Patch sound fine for me. Of course this code need to be ported to KDE4 (:=)))

Gilles

SVN commit 846543 by aclemens:

We need to initialize the albumsMap and tagsMap with all available information first before counting, so that empty albums and tags are updated correctly.


CCBUGS:160564
TODO:KDE4PORT


 M  +104 -93   digikamalbums.cpp  
 M  +27 -16    digikamtags.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=846543

I will close this one know, but it has to be ported to KDE4 as well. Right now this is not possible because

KIO::Job* scan(const KUrl& albumURL)

in dio.cpp is commented out, so the kioslaves actually don't update the counters at all.

Gilles, Marcel, I think there needs to be something implemented first in the albumdb interface? So this is why it is commented out?

Andi

Andi,

I don't remember why this code is commented. Perhaps Marcel have do it.

Marcel, any idea ?

Note: Marcel is not in Europe for the moment (Autralia until October). So we need to take a care about this file if he don't see this mail (i'm not sure if he have wifi in hotel). I recommend to place an annotation in TODO file from trunk.

Gilles

Hi, I'm still alive ;-)
I actually have unfinished code lying on my laptop that listens to database signals to trigger updating everything that AlbumManager handles after the db is changed.
The relevant code parts fixed by this patch can now be found in albumdb.cpp, getNumberOfImagesInAlbums() and getNumberOfImagesInTags(). The code is different though, Andi you know better than me if the same fix is needed. 

"Jaaaa, er lebt noch, er lebt noch....." :D