Bug 181792 - Folders appear empty on first run after migrating from an old KDE version
Summary: Folders appear empty on first run after migrating from an old KDE version
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Scan (show other bugs)
Version: 0.10.0
Platform: Ubuntu Unspecified
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-01-24 19:35 UTC by Albert Astals Cid
Modified: 2017-07-25 19:20 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Albert Astals Cid 2009-01-24 19:35:18 UTC
Version:            (using KDE 4.1.96)
Installed from:    Ubuntu Packages

digikam --version
Qt: 4.4.3
KDE: 4.1.96 (KDE 4.1.96 (KDE 4.2 RC1))
digiKam: 0.10.0-rc1

I just installed a KDE4 based digikam for the first time, when running it, it had all the structure of my albums correct (left screen tree) but when selecting any item there no photo was shown on right.

After a close/open of digikam all is fine now, but still think it would be a good idea to fix this as some users might die of a heart attack (not me as i just backuped all my photos yesterday :D)
Comment 1 Albert Astals Cid 2009-01-24 20:14:29 UTC
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.
Comment 2 Marcel Wiesweg 2009-01-24 22:55:24 UTC
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?
Comment 3 Matthias Welwarsky 2009-01-25 11:02:42 UTC
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.
Comment 4 Matthias Welwarsky 2009-01-25 11:11:26 UTC
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)
Comment 5 caulier.gilles 2009-01-25 11:59:11 UTC
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
Comment 6 Albert Astals Cid 2009-01-25 22:27:51 UTC
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
Comment 7 caulier.gilles 2009-01-25 23:01:40 UTC
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

Comment 8 Marcel Wiesweg 2009-01-26 22:28:26 UTC
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.
Comment 9 S. Burmeister 2009-01-26 22:46:05 UTC
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.
Comment 10 caulier.gilles 2009-01-26 22:51:11 UTC
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
Comment 11 Andi Clemens 2009-01-26 22:51:39 UTC
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
Comment 12 Andi Clemens 2009-01-26 22:52:25 UTC
By confirming I mean that deleting the digiKam4.db and importing the old one from KDE3 will result in an empty iconview.

Andi
Comment 13 caulier.gilles 2009-01-26 23:03:22 UTC
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
Comment 14 Marcel Wiesweg 2009-01-27 10:09:40 UTC
Sorry guys, yes of course I can reproduce that, I just had moved my digikam3.db.
Comment 15 Matthias Welwarsky 2009-01-27 10:47:59 UTC
(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.

Comment 16 caulier.gilles 2009-01-27 11:15:58 UTC
>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
Comment 17 Marcel Wiesweg 2009-01-29 12:52:21 UTC
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
Comment 18 caulier.gilles 2017-07-25 19:20:09 UTC
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.