Version: 0.9.4-beta4 (using 3.5.9, Arch Linux) Compiler: Target: i686-pc-linux-gnu OS: Linux (i686) release 2.6.24-ARCH I discovered that the "quick filter lamp / indicator" is not working properly in recursive album view mode. I have a folder structure that can be seen in my attached screenshot. In album3c is an image rated with 5 stars. When I enable the quick filter for ratings >=5 and click on the toplevel album 'root' (which is not the album root of digikam, just a normal folder), the former green lamp becomes red, although the image rated with 5 stars is visible in the image list window. When I click on the parent folder of album3c ('album3'), the lamp is green again. The strange thing is that this problem is not reproducible in all of my image folders. I have another folder, lets call it 'root2', that has nearly the same structure and folder depth. When I tag an image in '/root2/album3/album3c' with a rating of 5 stars, activate the quick filter and click on 'root2', the lamp stays green. My first thought was that maybe the folder depth might be an issue so I rebuild the structure of 'root' (lets call it 'root3' for now) and copied one image in every folder. I rated the image in '/root3/album3/album3c' with 5 stars, activated the quick filter and clicked on the 'root3' folder. But surprisingly the lamp staid green as well, although the original tree turned the lamp to red. In the next step I copied the exact amount of images into the folders (like in the screenshot) and then the problem was reproducible again. So not only the folder depth might be the problem, also the amount of images in those folders could be an issue. I played around with the images in the 'root3' folder, rated some images and recognized that when I rate an image in folder '/root3/album9' (the last one in the tree) and click with the quick filter activated on the 'root3' folder, the lamp turns green. Un-rating the image in 'album9' and clicking on the 'root3' folder turns the lamp red again. One thing that can be recognized is that the lamp turns green for half a second, then red, then green again and finally red (it flickers). So I guess while running through the underlaying folders, the status of the lamp is changed 4 times, resulting in "the red state" altough this is wrong. So to sum it up: Not only the structure and depth of the folders seem to be an issue, also the amount of images and even the "position" of the rated or tagged images is responsible for this bug. It is hard to describe and even harder for you guys to reproduce it I think, but if you build a folder structure like in my screenshot and copy the same amount of images in there, you hopefully see what I'm trying to tell you here :-) I also attach a PDF were I try to show what ratings in which folder turn the light / lamp / indicator green and red. Hope you understand what I want to say here, my bad english even got worse today... I don't understand a single thing I'm writing here... :-) PS.: I found another issue: When quick filter is enabled and I remove a rating from >70 images, digiKam crashes, if I disable the quick filter, everything is fine and I am able to un-rate the images.
Created attachment 24541 [details] folder structure
Created attachment 24542 [details] OBSOLETE: report showing the different states of the quick filter indicator
Created attachment 24543 [details] OBSOLETE: report showing the different states of the quick filter indicator somehow the PDF seems to be broken, I was not able to open it anymore. I'll attach a new version...
Created attachment 24554 [details] test cases added some more test cases and a screenshot showing the problem
Andi, Thanks for this great document. If you want to hack code, all is in ImageFilter : http://websvn.kde.org/branches/extragear/kde3/graphics/digikam/digikam/albumlister.cpp?revision=786938&view=markup especially look signals : void signalItemsTextFilterMatch(bool); // dedicated to toogle background color of status bar search text filter. void signalItemsFilterMatch(bool); // dedicated to toogle status bar filter light color. Gilles Caulier
>If you want to hack code, all is in ImageFilter : Sorry, AlbumLister class i want mean (:=))) Gilles
Well I already looked in AlbumLister and played around with gdb to find the problem... Maybe I'll come to a conclusion and post a patch here.
Created attachment 24578 [details] possible patch for filter indicator lamp issue
Hi Mik, Gilles asked me to leave a comment here to ask you to test this patch. If you want to test it, make sure to have the same folder structure and amount of images in there like in my attached screenshot, otherwise the bug might not be seen at all. It is not happening all the time, so creating this folder structure is necessary (you do not have to name all folders like shown in the image, but the depth and amount of images is really important). Thanks in advance Andi
Mik, Please take a look in patch from Andi (look message from #9). Please test indeep status bar indicator and report if all is fine for you. Thanks in advance. Gilles Caulier
Sorry, didn't notice this message earlier. 1) couldn't reproduce original bug 2) applied patch, nothing seems broken so if it fixes this corner case... 3) cannot confirm crash when de-tagging many images at once; it takes some times, rating widget in right panel flickers but everything works
Hi, I still can confirm the crashing while the rating quick filter is enabled. If I set this filter to (=1) and remove or change the rating of the displayed images, digiKam just crashes, but only if I remove / change the rating of more than 7 images... very strange.
Andi, could you run this with a debug build of digikam to obtain a proper backtrace with gdb? Maybe Gilles can make a sense of the backtrace to solve the issue .... Thanks a lot, Arnd
Andi, What's the GDB backtrace exactly ? Gilles
Created attachment 24860 [details] Backtrace
Created attachment 24861 [details] Backtrace the first one is not opening in my browser, hopefully this attachment works now
Just a comment: When I run digiKam in Kdevelop using the debugger, it crashes here: ============================= itemgroupitem.cpp (line 115) ============================= IconItem* IconGroupItem::firstItem() const { return d->firstItem; }
I mean icongroupitem.cpp
Sometimes it crashes in iconitem.cpp as well: ============ iconitem.cpp ============ bool IconItem::isSelected() const { return m_selected; }
I just reverted the file 'albumlister.cpp' to check if my patch may be responsible for the crash, but still the same behavior. So I don't think it has anything to do with the indicator lamp issue... maybe a new bugreport would be better?
Andy, The crash is not reproductible here. I use Kdevelop everyday to hack digiKam... clean up all source code, make a fresh checkout, and recompile and install all. ... and try to reproduce it Gilles
It crashes with the official packages from archlinux (0.9.3) as well as with the tarball from the digikam website (beta4) and the SVN version (beta5). All of the three versions show this behavior.
Ok maybe I should demonstrate how I reproduce the effect: 1. Select an album in the album view 2. select more than 10 images, to make it easy just select all 3. Assign a rating of 3 4. Assign a quick filter with a rating (>=3) 5. select all images again 6. remove the rating from all images while quickfilter is active It should crash right now.
I just fired up my Ubuntu virtualbox, installed digikam (0.9.3), copied some images in there and created a new database... This version also crashes, so I don't think it has anything to do with my system here, it seems to be a "real" bug.
to Andy, #23 I confirm : no crash here... after step 6. all icons diseapear and status indicator become red... as espected. Gilles
It is not always, sometimes I have to redo all the steps... but 10 minutes ago as I checked the package from Ubuntu 8.04 it crashed immediately.
Marcel, Gerhard, Arnd, Mik, Are you able to reproduce the crash from #23 ? Gilles Caulier
Gilles, I could not reproduce this bug... Julien
This is interesting, though I don't know why it happens: DigiKam only crashes when the window is maximized (not fullscreen), if I shrink the window so that only 4 or 6 images are listed in the album view, the crash is not reproducible. If I maximize it (15 images are listed), it crashes. This behavior can be reproduced in Archlinux using all three versions mentioned in #22 and in Ubuntu 8.04 using the official package.
Another interesting fact: It only crashes when using the keyboard shortcut, NOT when using the menu item. Again can be reproduced in all mentioned versions and linux distributions.
Julien, thanks for the feedback Andy, which keyboard shortcuts exactly ? Gilles
The one for removing a rating (CTRL+0), I also used an alternate one (just the 0), but it also crashes. When using the context menu, it does not crash.
I can reproduce the bug with keyboard shortcuts. Gilles, if you want a proper backtrace I can recompile with debug symbols. Julien
Yes, a backtrace can be suitable Gilles
What can be recognized just by watching the program do its job: When using the keyboard shortcut, images are removed from the view while assigning the rating. When using the context menu, no images are removed until the rating is done completely.
Andi, Julien, I'm still not able to reproduce the crash here, using keyboard shortcuts... Gilles
Hmm so its 2:1... we win!!! ;-) I don't know why it is happening, but I tried it on a totally different computer now (my fileserver, where I installed KDE just for this test). It is a Debian system. Crash can be confirmed as well.
Gilles, Tell me if this helps. Julien Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1250280832 (LWP 29304)] [KCrash handler] #6 0xb7c68cba in Digikam::IconItem::isSelected (this=0x2f0032) at iconitem.cpp:126 #7 0xb7c12f80 in Digikam::AlbumIconView::slotAssignRating (this=0x81324a0, rating=1) at albumiconview.cpp:2370 #8 0xb7c52472 in Digikam::DigikamView::slotAssignRatingOneStar ( this=0x812e388) at digikamview.cpp:1423 #9 0xb7c58be7 in Digikam::DigikamView::qt_invoke (this=0x812e388, _id=96, _o=0xbfceb3ac) at digikamview.moc:535 #10 0xb6104893 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #11 0xb6105338 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #12 0xb6a6f3d9 in KAction::activated () from /usr/lib/libkdeui.so.4 #13 0xb6ab1ca2 in KAction::slotActivated () from /usr/lib/libkdeui.so.4 #14 0xb6bafb2f in KAction::qt_invoke () from /usr/lib/libkdeui.so.4 #15 0xb6104893 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #16 0xb6105338 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #17 0xb6793109 in KAccelPrivate::menuItemActivated () from /usr/lib/libkdecore.so.4 #18 0xb67e0b17 in KAccelPrivate::emitActivatedSignal () from /usr/lib/libkdecore.so.4 #19 0xb684b17e in KAccelPrivate::eventFilter () from /usr/lib/libkdecore.so.4 #20 0xb6103e40 in QObject::activate_filters () from /usr/lib/libqt-mt.so.3 #21 0xb6103ebe in QObject::event () from /usr/lib/libqt-mt.so.3 #22 0xb613b5b3 in QWidget::event () from /usr/lib/libqt-mt.so.3 #23 0xb6211c5a in QMainWindow::event () from /usr/lib/libqt-mt.so.3 #24 0xb609baf0 in QApplication::internalNotify () from /usr/lib/libqt-mt.so.3 #25 0xb609dac0 in QApplication::notify () from /usr/lib/libqt-mt.so.3 #26 0xb687ccd2 in KApplication::notify () from /usr/lib/libkdecore.so.4 #27 0xb67eeaf7 in KAccelEventHandler::x11Event () from /usr/lib/libkdecore.so.4 #28 0xb687b103 in KApplication::x11EventFilter () from /usr/lib/libkdecore.so.4 #29 0xb601a153 in ?? () from /usr/lib/libqt-mt.so.3 #30 0xbfcebee0 in ?? () #31 0xbfcebca8 in ?? () #32 0x00000001 in ?? () #33 0xb65cc8d0 in ?? () from /usr/lib/libqt-mt.so.3 #34 0xbfcebca8 in ?? () #35 0xb65cc8d0 in ?? () from /usr/lib/libqt-mt.so.3 #36 0xbfcebb48 in ?? () #37 0xb602a8e2 in QApplication::x11ProcessEvent () from /usr/lib/libqt-mt.so.3 Backtrace stopped: frame did not save the PC
Well this is nearly the same backtrace I posted before... so we have the same issue going on here...
Just to be sure, here is a new backtrace (because of huge differences dicussed in IRC): Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 0xb5a1f8e0 (LWP 25033)] [KCrash handler] #6 0xb7cb41b3 in Digikam::AlbumIconItem::imageInfo (this=0x89fb2d0) at albumiconitem.cpp:159 #7 0xb7cbcd55 in Digikam::AlbumIconView::slotAssignRating (this=0x8795020, rating=0) at albumiconview.cpp:2248 #8 0xb7cfbeb6 in Digikam::DigikamView::slotAssignRatingNoStar (this=0x8790fd0) at digikamview.cpp:1418 #9 0xb7d026b7 in Digikam::DigikamView::qt_invoke (this=0x8790fd0, _id=94, _o=0xbfc407f4) at digikamview.moc:534 #10 0xb628b558 in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3 #11 0xb628d3e3 in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3 #12 0xb6afafa4 in KAction::activated () from /opt/kde/lib/libkdeui.so.4 #13 0xb6b406eb in KAction::slotActivated () from /opt/kde/lib/libkdeui.so.4 #14 0xb6be4f05 in KAction::qt_invoke () from /opt/kde/lib/libkdeui.so.4 #15 0xb628b558 in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3 #16 0xb628d3e3 in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3 #17 0xb683bd6e in KAccelPrivate::menuItemActivated () from /opt/kde/lib/libkdecore.so.4 #18 0xb685db99 in KAccelPrivate::emitActivatedSignal () from /opt/kde/lib/libkdecore.so.4 #19 0xb692f7c1 in KAccelPrivate::eventFilter () from /opt/kde/lib/libkdecore.so.4 #20 0xb628b5fb in QObject::activate_filters () from /opt/qt/lib/libqt-mt.so.3 #21 0xb628b664 in QObject::event () from /opt/qt/lib/libqt-mt.so.3 #22 0xb62c1c4d in QWidget::event () from /opt/qt/lib/libqt-mt.so.3 #23 0xb6378273 in QMainWindow::event () from /opt/qt/lib/libqt-mt.so.3 #24 0xb622b7c3 in QApplication::internalNotify () from /opt/qt/lib/libqt-mt.so.3 #25 0xb622d2df in QApplication::notify () from /opt/qt/lib/libqt-mt.so.3 #26 0xb6927154 in KApplication::notify () from /opt/kde/lib/libkdecore.so.4 #27 0xb68515fc in KAccelEventHandler::x11Event () from /opt/kde/lib/libkdecore.so.4 #28 0xb692c54d in KApplication::x11EventFilter () from /opt/kde/lib/libkdecore.so.4 #29 0xb61b7f5d in ?? () from /opt/qt/lib/libqt-mt.so.3 #30 0xbfc41194 in ?? () #31 0xbfc41088 in ?? () #32 0x00000001 in ?? () #33 0xb66d75a4 in ?? () from /opt/qt/lib/libqt-mt.so.3 #34 0xb66d75a4 in ?? () from /opt/qt/lib/libqt-mt.so.3 #35 0x00000013 in ?? () #36 0xbfc40f38 in ?? () #37 0xb61c62dc in QApplication::x11ProcessEvent () from /opt/qt/lib/libqt-mt.so.3 Backtrace stopped: frame did not save the PC
SVN commit 812423 by cgilles: try to fix crash with rating keyboard shortcuts. CCBUGS: 161369 M +13 -10 albumiconview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=812423
Created attachment 24931 [details] after applying the patch
Created attachment 24932 [details] backtrace after applying SVN changes
==> Marcel, What do you think about the backtrace reproted by Andy. It's sound like a race condition. Or... ...something change iconviewitem instance in memory (corruption) ? Can you reproduce the crash ? (me i cannot). Look #23 for details. ==> Mik, Are you able to reproduce the crash on your computer ? Gilles
Created attachment 24933 [details] valgrind output (including normal debugging output from digikam)
Some notes concerning the crashing of digikam while rating images using a quickfilter: When using valgrind, the program is running very slow, so you can actually see exactly what is going on. When using the context menu, the images are displayed in the quick filter until all rating is done, using the keyboard shortcut, they disappear while assigning the rating. For example the first row in the iconview contains 4 images. The quickfilter is set and the rating will be removed with the keyboard shortcut. After a while, the first row disappears from the iconview, while the forth image (the last in the row) is still assigned with the new rating. After that, digiKam crashes. Using the context menu, everything is displayed until the rating is done completely.
One little note, for those of you who are not able to reproduce the crash. When you have enabled the following setting: Settings->Metadata->Common Metadata Actions->save image rating as tags the chance is that digiKam runs so slow that the error will not appear. So try to uncheck this option and redo the steps from #23
SVN commit 812500 by cgilles: second try to fix Rating assign from keybord shortcuts CCBUGS: 161369 M +5 -3 albumiconview.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=812500
SVN commit 812506 by cgilles: same problem here. we need to block AlbumLister when Rating is assigned CCBUGS: 161369 M +3 -0 imagedescedittab.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=812506
SVN commit 812510 by cgilles: Same problem here with tags assignement and tags filter about AlbumLister handling CCBUGS: 161369 M +2 -0 digikam/albumiconview.cpp M +2 -0 digikam/tagfilterview.cpp M +4 -1 digikam/tagfolderview.cpp M +3 -0 libs/imageproperties/talbumlistview.cpp M +2 -2 project/project.kdevelop WebSVN link: http://websvn.kde.org/?view=rev&revision=812510
SVN commit 812535 by cgilles: backport commits #812500, 812506, 812510 from KDE branch CCBUGS: 161369 M +25 -23 digikam/albumiconview.cpp M +15 -15 digikam/tagfilterview.cpp M +16 -15 digikam/tagfolderview.cpp M +30 -24 libs/imageproperties/imagedescedittab.cpp M +16 -15 libs/imageproperties/talbumlistview.cpp M +18 -2 project/project.kdevelop WebSVN link: http://websvn.kde.org/?view=rev&revision=812535
Andy, i'm back to the origin problem from this thread. Can you check if your can reproduce the problem to enable all Metadata settings in config panel ? Note : this is my configuration... Gilles
Created attachment 24939 [details] video showing the indicator issue
I tested again the indicator lamp issue, and the problem is that filtering is done for every single image... look at albumlister.cpp:617-632: ImageInfo* info = new ImageInfo(imageID, albumID, name, QDateTime::fromString(date, Qt::ISODate), size, dims); if (matchesFilter(info, foundText)) { match = true; newFilteredItemsList.append(info); } newItemsList.append(info); d->itemList.append(info); if (foundText) matchForText = true; Every single time the two boolean vars matchForText and match are set so in recursive album view this results in the described problem. We have to call the slotFilterItems() or the timer instead of emitting the two signals in line 634 so the new filtered imagelist is scanned and the lamp is set to either green or red.
Created attachment 25403 [details] possible fix
Your patch sound fine. i will test it on my computers to be sure... Gilles
SVN commit 830037 by aclemens: When using a quick filter on an album in recursive view mode, the indicator lamp sometimes shows a wrong status. Filtering is now done after the whole recursive album view is generated, so that the lamp can set its state correctly. CCBUGS:161369 M +2 -11 albumlister.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=830037
SVN commit 830040 by aclemens: backport commit #830037 from KDE3 branch BUGS:161369 M +2 -11 albumlister.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=830040