Version: 0.9.4-svn (using KDE 3.5.9) Installed from: Gentoo Packages OS: Linux I have been doing some organization on my tags and I found the following (using the latest svn, from today): - On the left panel I displayed the tags tab. - Then I had a tag assigned to many pictures, it said something like "Tag Name (187)". So a tag name and the number of pictures between the brackets. - I clicked on the tag, so the pictures were displayed on the gallery. - I selected all pictures - Now, right click -> Remove a tag -> And selected the tag mentioned above "Tag Name". - The pictures that were using that tag dissapear from the gallery, which is normal. - But, and this is the bug, the number of pictures between the brackets for that tag is not modified, it still said "Tag Name (187)" - I try to close digikam and restart, and then the value is refreshed correctly saying 0. So, the problem occurs when we remove the tag from a picture, that apparently doesn't force to recount the number of images using the tag.
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