Bug 224038

Sound like kioslave won't to start on your computer. 

Do you have compiled digiKam yourself ?

Go Help/Compenents info to show all depencies

Gilles Caulier

I see multiple entries for kioslave in Task Manager as I start digikam.

I compiled using the emerge system on XP with SP3.

Component Information gives the following:-

digiKam version 1.1.0
Exiv2 can write to Jp2: Yes
Exiv2 can write to Jpeg: Yes
Exiv2 can write to Pgf: No
Exiv2 can write to Png: Yes
Exiv2 can write to Tiff: Yes
Exiv2 supports XMP metadata: Yes
LibCImg: 130
LibExiv2: 0.19
LibJPEG: 62
LibJasper: 1.900.1
LibKDE: 4.4.59 (KDE 4.4.59 (KDE 4.5 >= 20100107))
LibKExiv2: 1.0.0
LibKdcraw: 1.0.0
LibLCMS: 118
LibPGF: 6.09.44
LibPNG: 1.2.35
LibQt: 4.6.1
LibRaw: 0.8.5
LibTIFF: LIBTIFF, Version 3.8.2 Copyright (c) 1988-1996 Sam Leffler Copyright (c) 1991-1996 Silicon Graphics, Inc.
Marble widget: 0.10.0 SVN
Parallelized demosaicing: Yes
LibKipi: 1.0.0

It seems like the F5 is not needed. All I need to do is to wait for some time and then change directory in order to get the thumbnails visible. I have over 27,000 pictures in this album, I don't know if that is a factor or not.

Does digikam use the full cpu while you wait for the thumbnails?

No, the CPU is not at 100%, at least not once the digikam window is rendered. The thumbnails will never appear unless I change the directory viewed some time after the window has appeared. Changing directory too soon does not result in the thumbnails being shown. The CPU is not at 100% at this stage.

After compiling Digikam 1.0.0 under MaxOSX 10.6 using mac ports, I also can not see the thumbnails. I guess it is more an installation problem than a bug in Digikam. 
It seems to be a quite common problem of wrong Digikam installations. I have seen the same problem under linux in the past as well. Sometimes after updating Digikam, I had to log out / log in to see the thumbnails again.

It would be nice if there were some graphical feedback/error message stating that there is a problem with kioslave.

Julien

I have the same problem. It sometimes happens also after running digikam for some time. This is what I get as debug output:

[38896] Debug:digikam(38896)/kio (Slave) KIO::Slave::createSlave: createSlave "digikamalbums" for KUrl("digikamalbums:/Små bilder/?albumRoot=C:/Documents and Settings/David/Mina dokument/Mina bilder&albumRootId=2&databaseType=QSQLITE&databaseName=C:/Documents and Settings/David/Mina dokument/Mina bilder/digikam4.db")
[38896] Debug:digikam(38896)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on  "tcp://127.0.0.1:3477"
[7448] Debug:klauncher(7448)/kio (KLauncher) KLauncher::requestSlave: KLauncher: launching new slave  "D:/KDE2/bin/kioslave.exe"  with protocol= "digikamalbums"  args= ("kio_digikamalbums", "digikamalbums", "tcp://127.0.0.1:4780", "tcp://127.0.0.1:3477")
[7448] Debug:klauncher(7448)/kio (KLauncher) KLauncher::processRequestReturn: "D:/KDE2/bin/kioslave.exe" (pid 32720) up and running.
[32720] Debug:trying to load 'kio_digikamalbums'
[38896] Debug:digikam(38896)/kio (Slave) KIO::Slave::timeout: slave failed to connect to application pid= 32720  protocol= "digikamalbums"
[38896] Debug:digikam(38896)/kio (Slave) KIO::Slave::timeout: Houston, we lost our slave, pid= 32720
[38896] Debug:digikam(38896)/kio (Slave) KIO::Slave::timeout: slave died pid =  32720
[32720] Debug:kio_digikamalbums(32720) KIO::SocketConnectionBackend::connectToRemote: could not connect to  KUrl("tcp://127.0.0.1:3477")
[32720] Debug:kio_digikamalbums(32720)/kio (kioslave) KIO::SlaveBase::connectSlave: SlaveBase: failed to connect to "tcp://127.0.0.1:3477"
[32720] Debug:Reason: ""
[7448] Debug:klauncher(7448)/kio (KLauncher) KLauncher::slotFinished: process finished exitcode= 255 exitStatus= 0
[37020] Warning:QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-4080440' is still in use, all queries will cease to work.
[7448] Debug:klauncher(7448)/kio (KLauncher) KLauncher::slotGotOutput: Family none 
[7448] Family none
[7448] Debug:klauncher(7448)/kio (KLauncher) KLauncher::slotFinished: process finished exitcode= 0 exitStatus= 0

I can see that a kioslave process is started with the correct pid but it disappears quickly.

David

I have to correct myself. The kioslave processes don't disappear quickly. They stay open for some time, ranging from a few second to several minutes. I also have kioslave processes that never disappears, even though no digikam process is running.

I also can trigger the problem with the new albummodeltest. It sometimes runs nicely and finishes without any problems but sometimes it just freezes and I have to kill it. The debug output then is similar to the above:

QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/digikam (core) AlbumModelTest::ensureItemCounts: Waiting for Alb
umManager and the IOSlave to create DAlbums...
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::createSlave: createSlave "digikamdates"
for KUrl("digikamdates:?databaseType=QSQLITE&databaseName=C:/DOCUME~1/David/LOKALA~1/Temp/albummodeltest-15_19_57/digika
m4.db")
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: List
ening on  "tcp://127.0.0.1:1436"
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::createSlave: createSlave "digikamalbums"
 for KUrl("digikamalbums:?databaseType=QSQLITE&databaseName=C:/DOCUME~1/David/LOKALA~1/Temp/albummodeltest-15_19_57/digi
kam4.db")
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: List
ening on  "tcp://127.0.0.1:1437"
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::createSlave: createSlave "digikamtags" f
or KUrl("digikamtags:?databaseType=QSQLITE&databaseName=C:/DOCUME~1/David/LOKALA~1/Temp/albummodeltest-15_19_57/digikam4
.db")
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: List
ening on  "tcp://127.0.0.1:1438"
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: slave failed to connect to appl
ication pid= 5520  protocol= "digikamdates"
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: Houston, we lost our slave, pid
= 5520
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: slave died pid =  5520
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: slave failed to connect to appl
ication pid= 5524  protocol= "digikamalbums"
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: Houston, we lost our slave, pid
= 5524
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: slave died pid =  5524
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: slave failed to connect to appl
ication pid= 2640  protocol= "digikamtags"
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: Houston, we lost our slave, pid
= 2640
QDEBUG : AlbumModelTest::testPAlbumModel() qttest(1988)/kio (Slave) KIO::Slave::timeout: slave died pid =  2640

Can it be some timeout that is to short? Since the process lives for sometime after the debug message that it has died can it be that it some how starts to slow on Windows?

This bug is quite annoying since it can happen anytime during working with digikam that you all of a sudden don't see any pictures. I have not figured out a way of getting the pictures back quickly. Instead you have to click around and hope that it will come back, which it does eventually.

Yes I think it may be a timeout issue. After I start digikam and have the main window up, the hard disk is still being accessed a lot. It's only after the hdd accesses have slowed down or stopped that I can change directories and then get the thumbnails shown. So I am guessing that kioslave is busy accessing the hdd and is thus unresponsive to digikam for too long, but I don't know how that stuff works in reality. Once the disk cache contains the right data kioslave manages to respond in time and all is well until the disk cache is evicted and the process starts again.
David, if the bug annoys you, please vote for it if you have any votes spare.

In any case it's a kdelibs kio issue. We just tell KIO to start a job and wait for results.
If you are both working on Windows, it's most probably a Windows issue.

So that means that this report should be reassigned? To where?

As far as I can tell what happens is that the job never reports any result just debug output that the slave died.

Patrick Spendrin, who maintain KDE windows project is the best people to respond here...

Gilles Caulier

There are at least two different problems here.

One is that the slaves dies, or is regarded as dead because they start slowly. This problem maybe a generic kdelibs KIO problem or related to the implementation of the digikamslaves.

The other problem is related to digikams handling of errors with KIO jobs. I have done some more investigations and the job sends the signal result with the error code that the slave died. However as far as I can see the only thing done about it on the digikam end is to issue a kWarning with the error. The albummodeltest stops since it is waiting for a signalAllDAlbumsLoaded which is never emitted. I don't know if digikam also waits for this signal or if it waits for the data signal from the job, which is never emitted since the slave is dead. It would be nice to have some sort of notification that the reason no pictures are shown is that the slave died and a refresh button or something to try restart the slave/job. I am willing to help with this but I don't know where in the code to start looking.

This problem must be fixed in kdelibs on Windows! This has never been a problem on Linux. For you a workaround in the UI looks like a good solution for your problem at hand, but it is not maintainable to add workarounds to the UI for platform bugs which troubled us on a specific system for a specific version. And you will agree that we cannot require users to restart ioslaves manually...you dont use a hand crank to start your car? ;-)

I haven't yet seen any logic within these bugs. Similar bugs could occur in kate e.g. in the file view there (the kioslave just dies away). The real problem might not even be kioslave, but rather dbus as well. For those users on windows here: Please report your operating system and the compiler with which your packages had been compiled (the one you chose when installing KDE/digikam). Also since kioslaves are handled via dbus ipc, please check your firewalls for any issues or checks.

My OS is XP Home with SP3. As stated in the summary the compiler was set to mingw4 when I used emerge to build it. I tried launching digikam with my firewall turned off, it made no difference. Let me know if there are any other diagnostics I can do.

*** Bug 227640 has been marked as a duplicate of this bug. ***

Can you please test with digikam 1.7.0/kde 4.4.4 if bug is still there ?
There is an installer available here:
http://sourceforge.net/projects/digikam/files/digikam/1.7.0/digiKam-installer-1.7-win32.exe/download

Yes it does still occur with that version. It also occurs in the version I had built from SVN using kde 4.6.70.
From the logs above and looking at the source kdelibs/kio/kio/slave.cpp you can see that the kioslave launcher is failing to hear back from the kio_digikamalbums even though it exists. Also the retry mechanism to wait for a slow slave is not being triggered (no 'slave is slow' messages). So kio_digikamalbums appears to be unresponsive for some time after its creation and the launcher cannot even tell that it exists let alone communicate with it. I would guess that the time kio_digikamalbums is unresponsive is related to the size of the database (number of photos?) as there is heavy disk activity at this time. Waiting a short time (enough to get db into disk cache?) allows the slave to start if you do something such as change directory. If you wait too long it will fail again (db evicted from cache?). Increasing SLAVE_CONNECTION_TIMEOUT_MIN does allow the slave to start but I don't think that is an acceptable solution.

Thanks for your investigation there. Andrew.

So it's a problem related to Sqlite database initialization.

Marcel, some tips there ?

Andrew, what's about Mysql ? It's the same problem ? (if you can try of course)

Gilles Caulier

Database initialization is only done with the first request, for example when special(const QByteArray&) is called to list albums. In this method, the slave takes its time, but that is the sole purpose of an ioslave.

Database initialization is not done in kde_main which is called to construct the slave. One possible peculiarity here is the creation of a QCoreApplication, which is needed to load SQL plugins and support DBus.

I am no longer using Windows as I have switched to Ubuntu as my main OS so I can no longer assist with debugging this issue.

Created attachment 58106 [details]
digiKam 2.0 runing on macbook

Marcel,

The problem is the same here on my macbook with 2.0. kioslave do not run and nothing can be used (no album, no tag, no item, etc...)

IMPORTANT : 1.9.0 run fine here. Same computer, same shared libraries... No problem...

Conclusion : something is wrong with Database init into 2.x

Gilles Caulier

Any debug output? The equivalent of the ~/.xsession-errors file on linux.

Yes, I can start digiKam from a console and get a backtrace with full debug info.

Mac is like linux. It's Unix system, but without X11. I will try to get kioslave debug messages...

Gilles Caulier

Created attachment 58107 [details]
digiKam 1.9 runing on macbook

With 1.9.0 release, all work fine on my macbook...

Gilles Caulier

Marcel,

Look like i use KDE 4.5.x, not last 4.6.1 available on macport.

Jan said than 2.x run fine with KDE 4.6.1, not KDE 4.5.x. 

Anyway, it sound strange no ?

Gilles Caulier

Complete information what worked fine and what not with Mac OS X 10.6.6:

KDE 4.5.x with Digikam 1.9 or 1.8 (not sure anymore which version I had installed) no problems AFAIR.
KDE 4.6.0 with Digikam 1.9 no thumbnails shown
KDE 4.6.1 with Digiakm 1.9 as well as Digikam 2.0 the thumbnails are shown.

There is also a ticket in the MacPort bug tracker concerning this problem: https://trac.macports.org/ticket/28308
There are some more logs and some more people state that kdelibs 4.6.1 with Digikam 1.9.0 is working fine.

Created attachment 58125 [details]
digiKam 2.0 runing on macbook : the console trace

Marcel,

This is the full trace of digiKam starting from a console. I turned on all KDE debug space to have all information about kioslave...

Gilles Caulier

I see this:

digikam(49098)/kio (Slave) KIO::Slave::createSlave: createSlave "digikamalbums" for KUrl("digikamalbums:?<...>"
digikam(49098)/kdecore (kdelibs) KToolInvocation::klauncher: klauncher not running... launching kdeinit
digikam(49098)/kdecore (kdelibs) getBundle: getBundle( "/opt/local/lib/kde4/libexec/kdeinit4" ,  false ) called
<...>
digikam(49098)/kdecore (kdelibs) KToolInvocation::klauncher: klauncher not running... launching kdeinit
digikam(49098)/kdecore (kdelibs) getBundle: getBundle( "/opt/local/lib/kde4/libexec/kdeinit4" ,  false ) called
<...>
digikam(49098)/kdecore (kdelibs) getBundle: getBundle(): returning  "/Applications/MacPorts/KDE4/kdeinit4.app/Contents/MacOS/kdeinit4"
kdeinit4: Shutting down running client.
digikam(49098): couldn't create slave: "Cannot talk to klauncher: The name org.kde.klauncher was not provided by any .service files" 
digikam(49098)/kio (KIOJob) KIO::TransferJob::slotFinished: KUrl("digikamalbums:?databaseType=QSQLITE&databaseName=%2FUsers%2Fagnes%2FDocuments%2FPhotos%2Fdigikam4.db&connectOptions=&hostName=&userName=&password=")
digikam(49098)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished: KIO::SpecialJob(0x144d7ac40) QObject(0x0)
digikam(49098)/digikam (core) Digikam::AlbumManager::slotAlbumsJobResult:  Failed to list albums 
digikam(49098)/kdecore (kdelibs) getBundle: getBundle(): returning  "/Applications/MacPorts/KDE4/kdeinit4.app/Contents/MacOS/kdeinit4"
kdeinit4: Shutting down running client.
digikam(49098): couldn't create slave: "Cannot talk to klauncher: The name org.kde.klauncher was not provided by any .service files" 
digikam(49098)/kio (KIOJob) KIO::TransferJob::slotFinished: KUrl("digikamalbums:<...>")
digikam(49098)/kio (Scheduler) KIO::SchedulerPrivate::jobFinished
digikam(49098)/digikam (core) Digikam::AlbumManager::slotAlbumsJobResult:  Failed to list albums 

Looks like kdelibs are looking for essential services, which are not running, and then gives up to start the ioslave

Marcel,

I see too, but why with 1.9.0 all work fine, and not 2.0.0.

I installed other KDE application as kate and dolphin which work fine.

I will take the 1.9.0 trace from the console to compare.

Gilles Caulier

Created attachment 58129 [details]
digiKam 1.9 runing on macbook : the console trace

Marcel,

This is the full trace of digiKam 1.9.0 starting from a console. As for 2.0.0, I turned on all KDE debug space to have all information about kioslave...

Gilles Caulier

The 1.9 trace does not show the error message. Do 1.9 and 2.0 run with the same kdelibs? Then it cannot really be a kdelibs problem.

The very first error message seems to be this:

digikam(49098)/kio (Slave) KIO::Slave::createSlave: createSlave "digikamtags" for KUrl("digikamtags:?databaseType=QSQLITE&databaseName=%2FUsers%2Fagnes%2FDocuments%2FPhotos%2Fdigikam4.db&connectOptions=&hostName=&userName=&password=")
digikam(49098)/kio (KIOConnection) KIO::ConnectionServer::listenForRemote: Listening on  "local:/private/var/folders/dK/dKQe4t9NHcG6PDrHXkdLhU+++TI/-Tmp-/ksocket-agnes/digikamn49098.slave-socket"
digikam(49098): couldn't create slave: "Cannot talk to klauncher: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken." 
digikam(49098)/kio (KIOJob) KIO::TransferJob::slotFinished: KUrl("digikamtags:?databaseType=QSQLITE&databaseName=%2FUsers%2Fagnes%2FDocuments%2FPhotos%2Fdigikam4.db&connectOptions=&hostName=&userName=&password=")

which does not help either.

Maybe some library linking problems? Is there something like
ldd /usr/lib64/kde4/kio_digikamalbums.so
on Mac? Perhaps there are old digikam libraries in a place found when klauncher loads the ioslave?

>The 1.9 trace does not show the error message. Do 1.9 and 2.0 run with the same
>kdelibs? Then it cannot really be a kdelibs problem.

Yes, same KDELibs in both. Look my screenshots for details, including components info dialog.

>Maybe some library linking problems? Is there something like
>ldd /usr/lib64/kde4/kio_digikamalbums.so
>on Mac? Perhaps there are old digikam libraries in a place found when klauncher
>loads the ioslave?

yes, otool :

new-host-4:~ agnes$ otool -L /opt/local/lib/kde4/kio_digikamalbums.so
/opt/local/lib/kde4/kio_digikamalbums.so:
	/opt/local/lib/libdigikamcore.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libdigikamdatabase.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/opt/local/lib/libkio.5.dylib (compatibility version 5.0.0, current version 5.5.0)
	/opt/local/lib/libQtCore.4.dylib (compatibility version 4.7.0, current version 4.7.1)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 123.0.0)
	/opt/local/lib/libkfile.4.dylib (compatibility version 4.0.0, current version 4.5.0)
	/opt/local/lib/libkhtml.5.dylib (compatibility version 5.0.0, current version 5.5.0)
	/opt/local/lib/libktexteditor.4.dylib (compatibility version 4.0.0, current version 4.5.0)
	/opt/local/lib/libknotifyconfig.4.dylib (compatibility version 4.0.0, current version 4.5.0)
	/opt/local/lib/libkutils.4.dylib (compatibility version 4.0.0, current version 4.5.0)
	/opt/local/lib/libkdeui.5.dylib (compatibility version 5.0.0, current version 5.5.0)
	/opt/local/lib/libQtSvg.4.dylib (compatibility version 4.7.0, current version 4.7.1)
	/opt/local/lib/libQtNetwork.4.dylib (compatibility version 4.7.0, current version 4.7.1)
	/opt/local/lib/libQtXml.4.dylib (compatibility version 4.7.0, current version 4.7.1)
	/opt/local/lib/libQtGui.4.dylib (compatibility version 4.7.0, current version 4.7.1)
	/opt/local/lib/libnepomuk.4.dylib (compatibility version 4.0.0, current version 4.5.0)
	/opt/local/lib/libkdecore.5.dylib (compatibility version 5.0.0, current version 5.5.0)
	/opt/local/lib/libQtDBus.4.dylib (compatibility version 4.7.0, current version 4.7.1)
	/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
	/opt/local/lib/libsolid.4.dylib (compatibility version 4.0.0, current version 4.5.0)
	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)

==> /opt/local/lib/libdigikamcore.1.dylib is the problem ?

Gilles

Created attachment 58242 [details]
digiKam 2.0 running on macbook with KDE 4.6.1

Marcel,

On my macbook, i uninstalled all macport with KDE 4.5.5, and installed again all. This time KDE 4.6.1 is here.

I only installed 2.0, and all work fine.

I concluded that mixing 1.x and 2.0 is not compatible somwhere in kioslave.

Gilles Caulier

2.0 ioslaves support some new features (faces). I would have thought they are cross-compatible within limitations... even under Linux, there are often problems to have to generations of digikam installed in parallel

Marcel,

When i try to use 1.9.0 and 2.0.0 on the same mac computer, i switched between version to install one over other and vis versa. 

Typically, i installed 1.9.0 over 2.0.0 on the system to use 1.9.0, and vis versa. Both version are installed at the same place.

Shared libs still the same. Only kioslave and digikam core libraries change.

Gilles Caulier

Andrew,

This file still valid using digiKam 2.3.0 fro windows ?

Gilles Caulier

Created attachment 66789 [details]
Screenshot after starting digikam 2.3 on windows; scan on startup enabled

yes, the file is still valid.

(In reply to comment #40)
> yes, the file is still valid.

Can you see thumbnails in other folders? If so, can you try quitting digiKam, restarting your computer, then moving all non-photos from that folder and sub-folders and re-opening digiKam?

-Ananta

I can press F5 and the thumbnails are shown.
After restarting digikam, the folder looks empty again.

Hi Gilles, As I said above in #22, I am no longer using XP as my main OS. But as you asked I just tried to see if I could reproduce this using VirtualBox. It took a while to sort out, but yes I can still reproduce the same behaviour using 2.3.0.

Git commit 38843d5cb19b3a064e62716f208a9e9ebb8b1b91 by Gilles Caulier.
Committed on 06/03/2012 at 23:16.
Pushed by cgilles into branch 'master'.

Remove digiKam kio-slave dependencies with digikamcore shared library.
By this commit, we limit external shared lib influence to kio-slave. For ex, why we need to link kio-slave with
Marble shared lib which is linked to digikamcore and can break binary compatibility when user update external packages.
This commit link digiKam kio-slave only with digikamdatabase. This will limit shared libs to load at kio-slave start, which
can be faster and prevent time-out under MACOSX and Windows.
Related: bug 294835

M  +2    -1    digikam/CMakeLists.txt
M  +2    -7    kioslave/CMakeLists.txt

http://commits.kde.org/digikam/38843d5cb19b3a064e62716f208a9e9ebb8b1b91

*** Bug 295445 has been marked as a duplicate of this bug. ***

(In reply to comment #42)
> I can press F5 and the thumbnails are shown.
> After restarting digikam, the folder looks empty again.

Rainier and anyone else using Windows, can you try digiKam 3.1.0 and let us know if the problem still persists? There were changes to the way digiKam watches folders and files which may solve your problem (it has fixed other, similar problems). The installer can be downloaded here:
   http://download.kde.org/stable/digikam/digiKam-installer-3.1.0-win32.exe

Everyone has seen the previous message from Ananta ?

This problem still exist with digiKam 3.x serie ?

Gilles Caulier

As all my problem discovered around this file under OSX are solved since my commit #38843d5cb19b3a064e62716f208a9e9ebb8b1b91 fromm comment #44, i close this file as WORKFORME. Reopen is necessary...

Gilles Caulier