Version: 9.3 (using KDE 3.5.8) Installed from: Ubuntu Packages OS: Linux When using an external application like gimp to work on a image managed by digikam and saving the results under a different filename in the same directory as the original file, digikam does not show the new image until digikam is shut down and started anew. This behaviour does show up in 100% of the cases. Especially in almost empty directories, digikam seemed to grab the change and show the new files. In directories with more than 100 pictures it never noticed the new files created by an external application.
To Marcel, This is relevant of the KDirWatch/FAM method used to listen changes in folders. Here of course, if a new appplication create a new files supported by digiKam (dixit mimetype settings) all work fine... in general... But sometime, i have seen some problem. It sound like a race condition. This subject have been already talked in IRC if you remember. So to debug this problem it really difficult on my computer. In 90% of cases, all work fine. It will be more easy to investiguate on Marcus computer because the problem is always reproductible. To Marcus, Please, checkout digiKam from svn (KDE3 branch) and look at the startup on the console : there is a new message from KDirWatch to ask which setting is used on your computer to handle changes from your disk. Here i have : digikam kbuildsycoca running... Found dcraw version: 8.82 digikam: KDirWatch method = FAM digikam: ImagePlugin_Core plugin loaded digikam: ImagePluginLoader: Loaded plugin ImagePlugin_Core ... FAM service is the better one to use. Gilles Caulier
Hello Gilles, tested with a fresh compile of the svn version. When starting up it shows digikam: KDirWatch method = INotify How can I change this to FAM? the following fam packages are installed: dpkg -l | grep fam ii fam 2.7.0-13 ~ File Alteration Monitor ii libfam-dev 2.7.0-13 ~ Client library to control the FAM daemon - development files ii libfam0 2.7.0-13 ~ Client library to control the FAM daemon Regards - Markus P.S: This startup message looks scary: digikam: WARNING: sqlite_step error: database disk image is malformed on query: SELECT Albums.url||'/'||Images.name FROM Images, Albums WHERE Images.dirid=Albums.Id AND (Images.datetime is null or Images.datetime == ''); and now I remember that search is somewhat broken in the respect that simple search always end with an errormessage... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHx9M7xxUzQSse11ARApcFAKCG97pRHcgruwP7N0/3r2/yHKf/XgCgghsd 2wISbbNeVM4DCz1nFykxEHg= =U+BB -----END PGP SIGNATURE-----
Marcus, Sound like notification method from KDirWatch can be only changed at compilation. Look in code : http://websvn.kde.org/branches/KDE/3.5/kdelibs/kio/kio/kdirwatch.h?revision=484448&view=markup http://websvn.kde.org/branches/KDE/3.5/kdelibs/kio/kio/kdirwatch.cpp?revision=556220&view=markup ...and read the comment. It's very intructive... In fact, this depand of the kernel type/version used on your system. Marcel, are you seen this comment on the code about signals emit by KDirWatch : // ---------------------------------------------- signals: /** * Emitted when a watched object is changed. * For a directory this signal is emitted when files * therein are created or deleted. * For a file this signal is emitted when its size or attributes change. * * When you watch a directory, changes in the size or attributes of * contained files may or may not trigger this signal to be emitted * depending on which backend is used by KDirWatch. * * The new ctime is set before the signal is emitted. * @param path the path of the file or directory */ void dirty (const QString &path); /** * Emitted when a file or directory is created. * @param path the path of the file or directory */ void created (const QString &path ); /** * Emitted when a file or directory is deleted. * * The object is still watched for new creation. * @param path the path of the file or directory */ void deleted (const QString &path ); // ---------------------------------------------- ==> "When you watch a directory, changes in the size or attributes of contained files may or may not trigger this signal to be emitted depending on which backend is used by KDirWatch." In AlbumManager class, we only using "dirty", not "deleted" and "created" This can be the source of problem ??? Gilles
Gilles Caulier wrote: | In fact, this depand of the kernel type/version used on your system. hmm - so it's out of reach for most users | ==> "When you watch a directory, changes in the size or attributes of | contained files may or may not trigger this signal to be emitted | depending on which backend is used by KDirWatch." But here they mention only changes of existing files. In my case newly created files do not show up Regards - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHx+cgxxUzQSse11ARAhAZAJ470IsBq9+EtKxbjaEK6Z6UCsU6hACeIW66 3KYcGEB/U8G/6XDrBTa/bUw= =rUig -----END PGP SIGNATURE-----
Another remark on this bug: This fam/inotify bug will probably not be resolved too soon. Would it be possible to modify the "Album-refresh" action (F5-key) to do a hard re-read of the directory? I could easily live with this solution up to a final cure of kde/fam/inotify etc. Regards - Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyTEmxxUzQSse11ARAsB1AJ4rFbkRFvoSK62seavvZcCSE0i4SgCeI46j uPUWquWpDfUFpk9RDgbfyb4= =Ku7i -----END PGP SIGNATURE-----
SVN commit 780880 by mwiesweg: Modify debug message in dir watch code CCBUG: 158565 M +1 -1 albummanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=780880
To ensure the source of the problem I have slightly moved and modified the relevant debug message in slotDirty. The question now goes to Markus: With current svn, in your directory where you can reproduce the problem, do you see a message "Noticed file change in directory ..."?
Marcel, compiled the new version and when opening a file with gimp, modifying and saving back into the same directory under a new name I do get digikam: Noticed file change in directory /home/springm/pictures/test in the terminal window from which I started digikam-svn Best regards Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHyXhsxxUzQSse11ARAqVcAJ48lbO24YMBXfBE8gouA67Aq/IqFQCfU48z gDISAhOSZbf+oJqWkdMvYJc= =N6Fo -----END PGP SIGNATURE-----
Have you switched on the option Albums->Show count of items in all tree views? If yes, please test to switch it off, to rule out that any interaction occurs between the started ioslaves.
| ------- Additional Comments From marcel.wiesweg gmx de 2008-03-01 19:26 ------- No, it was switched off. Just now I tried it switched on, but it makes no difference -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHybMzxxUzQSse11ARApKkAJ97vCnHFGkm+mdzlB1cWnPWf6FVvQCfRLjQ ErGZvnSA27+m8FuvWIaq84s= =uMXr -----END PGP SIGNATURE-----
Marcel, What can be done to make progress here ? Where can be the problem ? kernel, famlib, KDirWatch, AlbumManager ? Gilles Caulier
According to Markus, the debug message appears: digikam: Noticed file change in directory /home/springm/pictures/test so the AlbumManager has obviously been notified by the KDirWatch, which means the problem lies on our side. But so far I dont have an idea where.
Please, look into http://bugs.kde.org/show_bug.cgi?id=162535 ...and check if way used by Thomas can solve your problem... Gilles Caulier
Marcel, Are you investigated about this problem ? Can you see a similar problem into 0.10.0 ? Gilles Caulier
When I test this with 0.10.0 it works for me, but it did already work with 0.9.x so this does not show anything. The relevant code has been rewritten so chances are high the bug is fixed, but it would be best of Markus could test this with 0.10.0-beta6.
Markus, We will release digiKam 0.10.0-beta7 soon. It will be nice to have a fresh feedback from you using this release to see if your problem is solved now. Thanks in advance Gilles Caulier
resolved in svn 883547