Version: (using KDE 3.5.8) Installed from: Ubuntu Packages Compiler: not of interest OS: Linux If you have applied a tag to a lot of pictures and you choose a new one and change those tags too, the changes will apply to all former selected pictures. For seeing this, applying of tags have to be in progress while changing next pictures tags.
Hi Lars, with digikam version? That you use kde 3.5.8 seem to indicate that you're using 7.10 (gutsy) and therefore digikam 0.9.2. Can you try 0.9.3 pkgs at http://www.mpe.mpg.de/~ach/kubuntu/gutsy/Pkgs.php I use these pkgs (of course ;) and can't reproduce it (maybe I'm too slow or maybe my laptop is too fast or maybe ...). Achim
Are you sure previous selection was deselected? It was my problem several times.
Lars, Can you test Achim package ? Gilles Caulier
Yes, I am sure. Mikolaj Machowski schrieb: [bugs.kde.org quoted mail]
I tested the Achim package and it has also the bug. May be it is because I have activated the automatically update. Gilles Caulier schrieb: [bugs.kde.org quoted mail]
I did not succeed to reproduce it with current svn (I think I was fast enough - progress bar was still moving - but maybe still not fast enough ... ;-)
Lars, What's new about this report ? it still valid using digiKam 0.9.4 ? Gilles Caulier
Confirming for 0.9.5svn . New action just kicks in while old is still performing. a) Select 1000 images b) assign A tag c) while b) still works assign B tag First 100 images has A tag, the rest A and B tags.
And for 0.10-b7svn also.
Very short term solution: Set wait cursor and block user interaction while assigning tags. Short term solution: Find out why a second drag solution has influence and the other operation. This is currently unclear to me. Do you use drag&drop and the tag sidebars, or do you use the metadata right sidebar to assign tags? Probably the latter... As a better solution, I would like to integrate this to Gilles' batch queue manager work-in-progress.
Marcel, This file is open with KDE3 code. Batch Queue Manager is for KDE4... Gilles
> Do you use drag&drop and the tag sidebars, or do you use the metadata right > sidebar to assign tags? Yes, using that one. But tried dragging to the Tag filters panel and it resulted in crash (0.10b7svn): Application: digiKam (digikam), signal SIGSEGV [?1034h[Thread debugging using libthread_db enabled] [Current thread is 1 (Thread 0xb4be36d0 (LWP 11921))] Thread 11 (Thread 0xb36b5b90 (LWP 11923)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0x08265679 in Digikam::ScanController::run () #4 0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x09a3ae00 in ?? () #6 0x00000000 in ?? () Thread 10 (Thread 0xb2452b90 (LWP 11926)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x09a788a0 in ?? () #6 0x00000000 in ?? () Thread 9 (Thread 0xb2c7fb90 (LWP 11927)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x09b750d0 in ?? () #6 0x00000000 in ?? () Thread 8 (Thread 0xb00b3b90 (LWP 12011)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281ec2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb049240b in metronom_sync_loop (this=0x9c8e808) at metronom.c:871 #3 0xb627e315 in start_thread () from /lib/i686/libpthread.so.0 #4 0xb584fdde in clone () from /lib/i686/libc.so.6 Thread 7 (Thread 0xaf452b90 (LWP 12016)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb5848101 in select () from /lib/i686/libc.so.6 #2 0xb04bb435 in xine_usec_sleep (usec=0) at utils.c:457 #3 0xb049fd8b in video_out_loop (this_gen=0x9c939c8) at video_out.c:1246 #4 0xb627e315 in start_thread () from /lib/i686/libpthread.so.0 #5 0xb584fdde in clone () from /lib/i686/libc.so.6 Thread 6 (Thread 0xaec51b90 (LWP 12017)): #0 0xb627f775 in pthread_mutex_lock () from /lib/i686/libpthread.so.0 #1 0xb516ad04 in ?? () from /usr/lib/libglib-2.0.so.0 #2 0xb516b0a8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #3 0xb63df717 in QEventDispatcherGlib::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4 #4 0xb63b76fa in QEventLoop::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0xb63b78ba in QEventLoop::exec () from /usr/lib/qt4/lib/libQtCore.so.4 #6 0xb62db4c3 in QThread::exec () from /usr/lib/qt4/lib/libQtCore.so.4 #7 0xb1c23879 in Phonon::Xine::XineThread::run () from /home/mikolaj/kde/lib/kde4/plugins/phonon_backend/phonon_xine.so #8 0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #9 0x09c92c18 in ?? () #10 0x00000000 in ?? () Thread 5 (Thread 0xae1d3b90 (LWP 12028)): #0 0xaf8981af in ao_alsa_handle_event_thread (data=0xa0a3aa8) at audio_alsa_out.c:176 #1 0xb627e315 in start_thread () from /lib/i686/libpthread.so.0 #2 0xb584fdde in clone () from /lib/i686/libc.so.6 Thread 4 (Thread 0xad9bfb90 (LWP 12030)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb04a2980 in ao_loop (this_gen=0xa0b9db8) at audio_out.c:345 #3 0xb627e315 in start_thread () from /lib/i686/libpthread.so.0 #4 0xb584fdde in clone () from /lib/i686/libc.so.6 Thread 3 (Thread 0xad1beb90 (LWP 12279)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x0bcd7c68 in ?? () #6 0x00000000 in ?? () Thread 2 (Thread 0xac1bcb90 (LWP 12448)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb6281b95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb62df0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb7788ba2 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb62de320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x0c7baa10 in ?? () #6 0x00000000 in ?? () Thread 1 (Thread 0xb4be36d0 (LWP 11921)): [KCrash Handler] #6 0xb63b7619 in QEventLoop::exit () from /usr/lib/qt4/lib/libQtCore.so.4 #7 0xb5cb38b4 in QDragManager::eventFilter () from /usr/lib/qt4/lib/libQtGui.so.4 #8 0xb63b8244 in QCoreApplicationPrivate::sendThroughApplicationEventFilters () from /usr/lib/qt4/lib/libQtCore.so.4 #9 0xb5c3e7a3 in QApplicationPrivate::notify_helper () from /usr/lib/qt4/lib/libQtGui.so.4 #10 0xb5c455e5 in QApplication::notify () from /usr/lib/qt4/lib/libQtGui.so.4 #11 0xb737b62d in KApplication::notify () from /home/mikolaj/kde/lib/libkdeui.so.5 #12 0xb63b8f91 in QCoreApplication::notifyInternal () from /usr/lib/qt4/lib/libQtCore.so.4 #13 0xb5c4697e in QApplicationPrivate::sendMouseEvent () from /usr/lib/qt4/lib/libQtGui.so.4 #14 0xb5ca3b3f in ?? () from /usr/lib/qt4/lib/libQtGui.so.4 #15 0x09b2ad40 in ?? () #16 0xbfe3a53c in ?? () #17 0x00000000 in ?? ()
SVN commit 896546 by mwiesweg: Operate with a copy of the metadata hub to avoid confusion when the method is called recursively (from processEvents) Note: Move metadata writing to threaded batch manager for after 0.10.0 CCBUG: 159855 M +12 -7 imagedescedittab.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=896546
I am confident that the original bug is fixed with my commit. Mikolaj, there is this crash you reported. I cannot reproduce it, can you? Anything special to do?
Afraid I don't have good news: Your patch have one - but IMO significant - side effect. After selecting images and selecting tag in right panel it is applied only after removing of selection. This gives impression that changes weren't applied at all. And still (rev. 896831, against 4.2) can reproduce crash: a) Use right Tags panel for assigning b) select many images and drag them to one of tags c) quickly - to perform it when previous writing is going - select one image and drag it onto another tag, choose "apply" -> crash Backtrace is a bit different: Application: digiKam (digikam), signal SIGSEGV [?1034h[Thread debugging using libthread_db enabled] [Current thread is 1 (Thread 0xb4bdb6d0 (LWP 18650))] Thread 10 (Thread 0xb36adb90 (LWP 18652)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0x08263ed9 in Digikam::ScanController::run () #4 0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x09f7a710 in ?? () #6 0x00000000 in ?? () Thread 9 (Thread 0xb2441b90 (LWP 18655)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb779b622 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x09f87d28 in ?? () #6 0x00000000 in ?? () Thread 8 (Thread 0xb2c42b90 (LWP 18656)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb779b622 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x0a06c820 in ?? () #6 0x00000000 in ?? () Thread 7 (Thread 0xb0083b90 (LWP 18745)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb635dec2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb045740b in metronom_sync_loop (this=0xa1c3f38) at metronom.c:871 #3 0xb635a315 in start_thread () from /lib/i686/libpthread.so.0 #4 0xb58f3dde in clone () from /lib/i686/libc.so.6 Thread 6 (Thread 0xaf41fb90 (LWP 18750)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb58ec101 in select () from /lib/i686/libc.so.6 #2 0xb0480435 in xine_usec_sleep (usec=0) at utils.c:457 #3 0xb0464d8b in video_out_loop (this_gen=0xa1c8780) at video_out.c:1246 #4 0xb635a315 in start_thread () from /lib/i686/libpthread.so.0 #5 0xb58f3dde in clone () from /lib/i686/libc.so.6 Thread 5 (Thread 0xaec1eb90 (LWP 18751)): #0 0xb635cb46 in __pthread_mutex_unlock_usercnt () from /lib/i686/libpthread.so.0 #1 0xb5380474 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #2 0xb5380dc4 in ?? () from /usr/lib/libglib-2.0.so.0 #3 0xb53810a8 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 #4 0xb64bb717 in QEventDispatcherGlib::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0xb64936fa in QEventLoop::processEvents () from /usr/lib/qt4/lib/libQtCore.so.4 #6 0xb64938ba in QEventLoop::exec () from /usr/lib/qt4/lib/libQtCore.so.4 #7 0xb63b74c3 in QThread::exec () from /usr/lib/qt4/lib/libQtCore.so.4 #8 0xb04a0879 in Phonon::Xine::XineThread::run () from /home/mikolaj/kde/lib/kde4/plugins/phonon_backend/phonon_xine.so #9 0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #10 0x0a1c7b10 in ?? () #11 0x00000000 in ?? () Thread 4 (Thread 0xae41db90 (LWP 18807)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb58e9367 in poll () from /lib/i686/libc.so.6 #2 0xaf864e93 in ao_alsa_handle_event_thread (data=0xa5d88b8) at audio_alsa_out.c:150 #3 0xb635a315 in start_thread () from /lib/i686/libpthread.so.0 #4 0xb58f3dde in clone () from /lib/i686/libc.so.6 Thread 3 (Thread 0xadc1cb90 (LWP 18809)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb0467980 in ao_loop (this_gen=0xa5ee1b0) at audio_out.c:345 #3 0xb635a315 in start_thread () from /lib/i686/libpthread.so.0 #4 0xb58f3dde in clone () from /lib/i686/libc.so.6 Thread 2 (Thread 0xad39fb90 (LWP 19106)): #0 0xffffe430 in __kernel_vsyscall () #1 0xb635db95 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/i686/libpthread.so.0 #2 0xb63bb0b2 in QWaitCondition::wait () from /usr/lib/qt4/lib/libQtCore.so.4 #3 0xb779b622 in Digikam::LoadSaveThread::run () from /home/mikolaj/kde/lib/libdigikamcore.so.1 #4 0xb63ba320 in ?? () from /usr/lib/qt4/lib/libQtCore.so.4 #5 0x0c1d7e70 in ?? () #6 0x00000000 in ?? () Thread 1 (Thread 0xb4bdb6d0 (LWP 18650)): [KCrash Handler] #6 0xb6493619 in QEventLoop::exit () from /usr/lib/qt4/lib/libQtCore.so.4 #7 0xb5c288b4 in QDragManager::eventFilter () from /usr/lib/qt4/lib/libQtGui.so.4 #8 0xb6494244 in QCoreApplicationPrivate::sendThroughApplicationEventFilters () from /usr/lib/qt4/lib/libQtCore.so.4 #9 0xb5bb37a3 in QApplicationPrivate::notify_helper () from /usr/lib/qt4/lib/libQtGui.so.4 #10 0xb5bba5e5 in QApplication::notify () from /usr/lib/qt4/lib/libQtGui.so.4 #11 0xb698585d in KApplication::notify () from /home/mikolaj/kde/lib/libkdeui.so.5 #12 0xb6494f91 in QCoreApplication::notifyInternal () from /usr/lib/qt4/lib/libQtCore.so.4 #13 0xb5bbb97e in QApplicationPrivate::sendMouseEvent () from /usr/lib/qt4/lib/libQtGui.so.4 #14 0xb5c18b3f in ?? () from /usr/lib/qt4/lib/libQtGui.so.4 #15 0x0cf5fec8 in ?? () #16 0xbff5565c in ?? () #17 0x00000000 in ?? ()
I got the idea: Probably we should not allow making new drags while we still handle the previous drag (and calling processEvents). Can be solved with a timer / queued signal, will do this. The other problem: > After selecting images and selecting tag in right panel it is applied only > after removing of selection. This gives impression that changes weren't > applied at all. I cannot reproduce this. Which right panel, tags filter or metadata edit? By removing selection you mean you have to click anywhere on the icon view to select another image and cause a repaint? For me, either using the metadata edit panel or dragging to the tag filter view either way, the new tag appears immediately in the album icon view after the database operation is done.
> > After selecting images and selecting tag in right panel it is applied > > only after removing of selection. This gives impression that changes > > weren't applied at all. > > I cannot reproduce this. Which right panel, tags filter or metadata > edit? Tags filter. > By removing selection you mean you have to click anywhere on the > icon view to select another image and cause a repaint? Yes. > For me, either using the metadata edit panel or dragging to the tag > filter view either way, the new tag appears immediately in the album > icon view after the database operation is done. For me not.
SVN commit 897734 by mwiesweg: When handling a drag event, calling processEvent() and thus allowing the user to start a new drag can cause a crash. In these cases, defer by emitting a queued signal. Consolidate progress code. CCBUG: 159855 M +29 -39 albumiconview.cpp M +8 -2 albumiconview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=897734
SVN commit 897735 by mwiesweg: When handling a drag event, calling processEvent() and thus allowing the user to start a new drag can cause a crash. In these cases, defer by emitting a queued signal. CCBUG: 159855 M +45 -30 digikam/tagfilterview.cpp M +5 -0 digikam/tagfilterview.h M +41 -25 digikam/tagfolderview.cpp M +5 -0 digikam/tagfolderview.h M +37 -26 libs/imageproperties/talbumlistview.cpp M +5 -0 libs/imageproperties/talbumlistview.h WebSVN link: http://websvn.kde.org/?view=rev&revision=897735
1. Crash isn't reproducible anymore 2. When dragging files into Tag filter tab everything works perfectly 3. Still exists problem with deselection required to start tagging files when using Caption/Tags tab
Downgrading severity of bug.
Mikolaj, this one is left: > Still exists problem with deselection required to start tagging files when > using Caption/Tags tab Are you sure that you pressed the apply button? Otherwise it is normal that you have to change selection to apply tags.
Lars, What news in this file still valid using digiKam 0.10.0-rc1 ? Gilles Caulier
Lars, Without a fresh feedback, we will close this file. Please test and report using digiKam 0.10.0-rc1. Thanks in advance Gilles Caulier
Mik, Are you seen comment #22 from Marcel ? Gilles Caulier
Any news here?
Please test with digiKam 1.0.0-beta5. Gilles Caulier
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier