Bug 178606

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.