Version: (using KDE 4.1.3) Installed from: SuSE RPMs When removing an image (move to trash) while viewing the thumbnails of an album, or while viewing an image, the image file is removed from the album, and probably, but not from the view nor the thumbnails, and probably not from the database. When you then switch albums, and come back again, the image is still there, allthough the file is already missing. Trying to remove it once more results in an error like "image file blabla cannot be found". When you exit digikam and start it again, there is a dummy image with a question mark at the location where the erased image used to be. Tried 0.10.0-60.12 from OpenSUSE KDE:KDE4:Stable as well as 0.10.0-60.16 from Factory. 32 bit.
Roman, Go to about dialog and report which digiKam version you use exactly, especially the beta id... We don't know Suse id... Gilles Caulier
> ... We don't know Suse id... Both times Version 0.10.0-beta6 Using KDE 4.1.3 (KDE 4.1.3) "release 68.1"
Ok. try beta7. I think it's fixed. Gilles Caulier
> Ok. try beta7. I think it's fixed. Still there. In a thumbnail view I clicked second image to view it, then I moved it to the trash. The image itself and its thumbnail in the row of thumnails below the image stayed. After exiting digikam and starting again, digikam shows a dummy icon instead of the erased image. The file itself is gone.
For me this problem does not occur, moving to trash makes the image disappear from all places. Please watch the console output of digikam and ensure that there is a line " Digikam::AlbumManager::slotDirty: AlbumManager::slotDirty "/path/to/deleted/image" "
I can confirm this, sometimes the image disappears, sometimes not. If not, you need to either restart digiKam or "scan for new images". Andi
> Please watch the console output of digikam and ensure that there is a line > " Digikam::AlbumManager::slotDirty: AlbumManager::slotDirty > "/path/to/deleted/image" " I double checked digikam's version number: 010.0-beta7 Prepared a directort AAA-Temp under the image root with just 16 images in it named p1.cr2 though p16.cr2, all of the Canon 350D RAWs Then I logged digikam's output and numbered the lines (see the comment lines for further details): # Inital state: #- Directory with a few Canon 350D CR2 RAW images #- digikam exited the last time while this directory was selected #- also did a Tools->Scan for new images to clean out non existant files from #the database before exiting # # Then I start digikam # # (digikam 2>&1) | nl | tee /tmp/digikam.log # # Removed the first 83 lines of log output. ... 84 Succesfully parsed file! 85 MapThemeId "earth/srtm/srtm.dgml" 86 loadMapTheme "earth/srtm/srtm.dgml" 87 Succesfully parsed file! 88 DGML2 Name : "Atlas" 89 Style reset requested. 90 THEME CHANGED: *** "earth/srtm/srtm.dgml" 91 Object::connect: No such signal Digikam::GPSSearchWidget::regionSelected(QList<double>) 92 Style reset requested. 93 Style reset requested. 94 Style reset requested. 95 Style reset requested. 96 Style reset requested. 97 digikam(11882)/KIPI (general) KIPIGalleryExportPlugin::Gallery::load: Reading data from kipirc file.. 98 Style reset requested. 99 Style reset requested. # here I clicked on the first image of the directory to view it # the image will be displayed, including the thumbnails (size 256) of the first four images in the directory 100 Warning: Directory Canon has an unhandled next pointer. 101 Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded. 102 Warning: Directory Canon has an unhandled next pointer. 103 Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded. # Here I right clicked on the first image, the full sized version, not # the thumbnail. Select "move to trash" in the pop up and again in the # dialog. It doesn't matter if I select the image name in the list of the # dialog or not. # As you can see, there's no additional output. :) # Then I exited digikam. 104 Style reset requested. 105 Found 354 GeoNode object LEAKS! 106 Found 4294967241 GeoNode object LEAKS! 107 Found 4294967237 GeoNode object LEAKS! 108 Model deleted: MarbleModel(0xa2015c0) 109 Style reset requested. 110 Found 4294967185 GeoNode object LEAKS! 111 Found 4294967241 GeoNode object LEAKS! 112 Found 4294967237 GeoNode object LEAKS! 113 Model deleted: MarbleModel(0x88d5910) 114 QSqlDatabasePrivate::removeDatabase: connection 'digikamDatabase-138476208' is still in use, all queries will cease to work.
What happens when you add or delete a file from the command line? Watch only for the AlbumManager::slotDirty lines. At startup, there is also a line printing your dirwatch method. It reads Digikam::AlbumManager::startScan: KDirWatch method = "INotify"
> At startup, there is also a line printing your dirwatch method. It reads > Digikam::AlbumManager::startScan: KDirWatch method = "INotify" I see, you are using the inotify mechanism. But I'm sorry, the output does not containg any line that comes close to it (fgrep -i 'watch'; fgrep -i 'notify'). I'm running this on a reiserfs 3.6, fs.inotify.max_user_watches = 65536. /proc/sys/fs/inotify $ cat max_queued_events 16384 /proc/sys/fs/inotify $ cat max_user_instances 128 /proc/sys/fs/inotify $ cat max_user_watches 65536 Also tested the used image directory using the inotify-tools from sourceforge. Do I have to turn anything on to see those messages, e.g. inside kdebugdialog or when starting digikam?
Digikam is using 50003 as kDebug channel, though kdebugdialog does not yet contain this for me here, perhaps comes with 4.2. I think debugging flags at compilation time can suppress kDebug as well. In your output I see mostly messages from Marble, some from libexiv2 and Qt, one from kipi, but none from digikam. I'd like to have proof that digikam gets KDirWatch info, but I am ready to believe that it works on your system, if Andi can confirm this problem. What happens if you permanently delete an image (Shift+Del), is it the same problem? May be the dir watch signal comes before the file is really removed? What happens if you move a first file to trash, then a second one, is the first one removed at second time?
First of all: I compiled digikam from SVN 904148. (In reply to comment #10) > Digikam is using 50003 as kDebug channel Added that to ~/.kde4/share/config/kdebugrc: [50003] InfoOutput=2 Just in case it'll help. > What happens if you permanently delete an image (Shift+Del), is it the same > problem? With 0.10.0-beta7: same thing With 0.10.0-beta8 (rev.: 904148M): same thing > May be the dir watch signal comes before the file is really removed? Output of 0.10.0-beta8 (rev.: 904148M), grep'd for dir watch and similar things gives me: digikam(1666) Digikam::AlbumManager::startScan: KDirWatch method = "FAM" No more "AlbumManager" lines to see. > What > happens if you move a first file to trash, then a second one, is the first > one removed at second time? No. But I tried the following: - removed 1. image, nothing was removed from the display - removed 2. image, nothing was removed from the display - removed 3.-5. image, at this point in time suddenly all images, 1.-5., where properly removed from the display. Suddenly digikam properly removed even single images, tried that with the 6. ad 8. image. I played around somewhat more and got the following additional information: - if I enter digikam and delete the first image from the thumbnail view, it works - if I enter digikam, view the first image and delete it from there it doesn't work - deleted images do not seem to be removed from the database. When I add an image from within digikam, exit digikam, readd the image on the CLI, enter digikam, the tags from the previously deleted image are back again. Is this related to the new menu entry "Update metadata database"?
> digikam(1666) Digikam::AlbumManager::startScan: KDirWatch method = "FAM" Ok, maybe we are talking about FAM peculiarities. > I played around somewhat more and got the following additional information: > > - if I enter digikam and delete the first image from the thumbnail view, it > works > - if I enter digikam, view the first image and delete it from there it doesn't > work This is interesting. As soon as the preview is loaded, a file watch will be installed onto the file itself. There is still a watch on the directory of course. Now, do you see debug entries with "LoadingCache slotFileDirty "? > - deleted images do not seem to be removed from the database. When I add an > image from within digikam, exit digikam, readd the image on the CLI, enter > digikam, the tags from the previously deleted image are back again. Is this > related to the new menu entry "Update metadata database"? No, this behavior is intended, info on removed images is not deleted immediately but preserved for a certain time, and if you bring back the image it will be recognized. (Btw, you would have similar behavior at least for tags if you write your tags to the metadata)
(In reply to comment #12) > Now, do you see debug entries with "LoadingCache slotFileDirty "? When it works, I see: Digikam::DeleteDialog::accept: setShowTrashDeleteDialog true Digikam::AlbumManager::slotDirty:AlbumManager::slotDirty "/srv/multimedia/images/AAA-Tem p" Digikam::AlbumManager::slotDirty:AlbumManager::slotDirty "/srv/multimedia/images" When it doesn't work, I do see nothing. As soon as I have time I'll have a look at the notify mechanism.
(In reply to comment #10) > I'd like to have proof that digikam gets KDirWatch info, ... I detected, that my system had gamin installed. When deselecting it, zypper/YaST insisted in installing fam. Ok, I installed fam, and tested again. This time KDirWatch uses INotify. Funny. But still, digikam removed the image file but not the displayed image, no slot dirty messages as before.
SVN commit 905532 by mwiesweg: In addition to KDirWatch (inotify, fam) use the org.kde.KDirNotify DBus interface to collect information about file changes. With this we ar guaranteed to be informed about all actions carried out by KDE ioslave, but nothing outside KDE. KDirWatch is in place to handle all remaining stuff, but it fails on some systems. I hope that KDirNotify will have a higher reliability in its smaller scope. CCBUG: 178606 M +76 -6 albummanager.cpp M +7 -1 albummanager.h WebSVN link: http://websvn.kde.org/?view=rev&revision=905532
Roman, with this commit I am pretty sure that your problem is fixed because the delete method from inside digikam will be carried out with KIO and thus detected by org.kde.KDirNotify. We have to live with KDirWatch failing on some systems, including yours, and fixing this is outside my scope. See last paragraph of this: http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/FileWatchService
(In reply to comment #16) > Roman, with this commit I am pretty sure that your problem is fixed ... It is as of 0.10.0-beta8 (rev.: 905554). > http://techbase.kde.org/Development/Tutorials/Metadata/Nepomuk/FileWatchService Never thought about that.