Bug 181792

If the database is stored on .kde i have a copy of kde3 one so i can try to reproduce the bug once a new version is out, etc or i can even send it to you if you want.

The database is digikam4.db in the same directory as digikam3.db was before.
Can you reproduce the bug when you a) remove the digikam4.db file or b) remove the digikam4.db and your digikamrc?
Did you start with a fresh digikamrc or reuse the one from KDE3 - if the latter and neither a) nor b), can you reproduce when you c) remove digikam4.db and again use your KDE3 digikamrc?

Actually, this also happens if you just delete digikam4.db so that digikam has to rebuild the database. The album scanning completes but then there are no images displayed, no matter what you try. Also, if you quit digikam afterwards, it blocks and never terminates, you have to kill it manually.

Once you start it again with the freshly built database, it works perfectly again.

Some additional info: Here's a backtrace of all threads from the "hanging" digikam.

(gdb) info threads
  9 Thread 0xae4e1b90 (LWP 4165)  0xb7f81430 in __kernel_vsyscall ()
  7 Thread 0xaf95fb90 (LWP 4163)  0xb7f81430 in __kernel_vsyscall ()
* 1 Thread 0xb49e56c0 (LWP 4153)  0xb7f81430 in __kernel_vsyscall ()
(gdb) thread apply all bt                                           

Thread 9 (Thread 0xae4e1b90 (LWP 4165)):
#0  0xb7f81430 in __kernel_vsyscall ()  
#1  0xb560df77 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb4cd7c32 in ?? () from /usr/lib/libglib-2.0.so.0     
#3  0xb4cd7f61 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#4  0xb638e478 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4
#5  0xb636252a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4          
#6  0xb63626ea in QEventLoop::exec () from /usr/lib/libQtCore.so.4                   
#7  0xb6270419 in QThread::exec () from /usr/lib/libQtCore.so.4                      
#8  0xb0245512 in ?? () from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so
#9  0xb62736ae in ?? () from /usr/lib/libQtCore.so.4
#10 0xb552450f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0xb56187ee in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 7 (Thread 0xaf95fb90 (LWP 4163)):
#0  0xb7f81430 in __kernel_vsyscall ()
#1  0xb55283a2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb5626a44 in pthread_cond_timedwait () from /lib/tls/i686/cmov/libc.so.6
#3  0xb01f567f in ?? () from /usr/lib/libxine.so.1

Thread 1 (Thread 0xb49e56c0 (LWP 4153)):
#0  0xb7f81430 in __kernel_vsyscall ()
#1  0xb560df77 in poll () from /lib/tls/i686/cmov/libc.so.6
---Type <return> to continue, or q <return> to quit---
#2  0xb4cd7c32 in ?? () from /usr/lib/libglib-2.0.so.0
#3  0xb4cd7f61 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#4  0xb638e478 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4
#5  0xb59a9ea5 in ?? () from /usr/lib/libQtGui.so.4
#6  0xb636252a in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4
#7  0xb63626ea in QEventLoop::exec () from /usr/lib/libQtCore.so.4
#8  0xb6364da5 in QCoreApplication::exec () from /usr/lib/libQtCore.so.4
#9  0xb590f767 in QApplication::exec () from /usr/lib/libQtGui.so.4
#10 0x082b4f92 in main (argc=1, argv=0xbff83454) at /home/matze/Sources/digikam-0.10.0-rc1/digikam/main.cpp:188
(gdb)

Albert,

Crash appears in Phonon using Xine library. You are not alone in this case. Sound like you have some video files in your collection.

Check Xine and Phono installation and try again

Gilles Caulier

Can you define "Check Xine and Phonon installation and try again" a bit better, i can play videos using dragonplayer, so it seems "correct" to me

Sorry, i can't (:=)))

Here, with KDE 4.1.3, i have no phonon/xine problem (Mandriva 2009.0)

Sound like with KDE 4.2, something is broken, but can't check why... You is not alone to report a similar backtrace.

In digiKam, we just embed phonon widget in main gui to only show video files. that all.

Gilles Caulier

Matthias: The funny story about your bt is that digikam does not seem to be hanging, it's just fine running in its event loop, but as there are no objects any more nothing will happend there and I dont know why it does not terminate after all windows are closed, and what is the connection to rebuilding the database.

Judging from your comment, the answer to my comment #2 is that you can always reproduce this just by removing digikam4.db (with digikam3.db in the same dir).
When this happens, can you look for output from the ioslaves? This is all lines starting with kio_digikam... usually in ~/.xsession-errors.
Thanks.

I could reproduce this by deleting the digikam4 file. After that I started digikam and it indexed the pictures but did not show them when the main window opened. After restarting it it worked.

The folder where the digikam4 file was situated contained also a digikam.db file and a digikam3.db file. After I deleted those, it now works without restarting.

Marcel,

deleting DB file and restarting digiKam, yes icon viewis empty _but_ because no album is selected by default at startup (at least welcome page view must be visible).

If i select an album, icon view is here. No need to restart digiKam.

Gilles

I can confirm this, it is also true (sometimes) when adding a new collection. All images from the newly added collection will not be visible, you have to restart digiKam.

Andi

By confirming I mean that deleting the digiKam4.db and importing the old one from KDE3 will result in an empty iconview.

Andi

Marcel,

Note : i don't have KDE3 database fiel to do regression tests. So my test is only to restart digiKam without database file.

Gilles

Sorry guys, yes of course I can reproduce that, I just had moved my digikam3.db.

(In reply to comment #8)
> Matthias: The funny story about your bt is that digikam does not seem to be
> hanging, it's just fine running in its event loop, but as there are no objects
> any more nothing will happend there and I dont know why it does not terminate
> after all windows are closed, and what is the connection to rebuilding the
> database.

Thread 7 seems to be blocked on a wait condition. Maybe the other threads are waiting for a termination signal from that thread? Gilles mentioned something about Phonon and Xine problems. Looking at the bt, thread 7 is inside libxine and thread 9 is inside phonon_xine backend code. I will check my collection for any AVI files (I think there is at least one).

> Judging from your comment, the answer to my comment #2 is that you can always
> reproduce this just by removing digikam4.db (with digikam3.db in the same dir).
> When this happens, can you look for output from the ioslaves? This is all lines
> starting with kio_digikam... usually in ~/.xsession-errors.

Will do, as soon as I'm back home today.

>Thread 7 seems to be blocked on a wait condition. Maybe the other threads are >waiting for a termination signal from that thread? Gilles mentioned something >about Phonon and Xine problems. Looking at the bt, thread 7 is inside libxine >and thread 9 is inside phonon_xine backend code. I will check my collection for >any AVI files (I think there is at least one). 

Yes, there are a lots of report with Phono+Xine Crash. I have fork these report to KDELibs/phonon bugzilla component. Sound like the issue is to update libxine.

Gilles Caulier

SVN commit 918131 by mwiesweg:

KIO jobs cannot be started from the non-UI thread.
Now when updating the database from 0.9, we used a KIO job from a worker thread,
and this worked well for this job. But in this case internal KIO objects
(KIO::Scheduler) will be created in this worker thread, so all following usage of KIO
from the main thread will fail, which caused the effect that no images are visible after
the first start when updating.
Fix with using QFile::copy methods in SchemaUpdater.

(KIO should enforce not being used from worker thread in KIO::Scheduler construction;
 or, there do not seem to be too large obstacles for creating per-thread usage to remove
 the restriction)

BUG: 181792

 M  +9 -7      schemaupdater.cpp  


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

This problem is relevant of digiKam KIO Slaves and all of these have been dropped in favor of a multi-threaded interface to query the database.