Bug 288761

Summary: cached image corrupted after modifying metadata
Product: [Applications] digikam Reporter: kde
Component: Albums-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 2.5.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 4.0.0
Attachments: corrupted image

Description kde 2011-12-11 21:58:00 UTC
Created attachment 66641 [details]
corrupted image

Version:           2.5.0 (using KDE 4.7.2) 
OS:                Linux

I've configured digikam to save metadata embedded in my picture files, which are usually jpg. Now when I modify metadata, i.e. assign or modify tags or ratings, the shown image gets updated, and often is corrupted, that is, only part of the picture remains visible, the rest is only one gray color. The saved file is not currupted, I guess you call it the cached image which is shown, which is corrupted.

I assume that this is caused by reloading the cached image while the disk file write hasn't completely finished. This happens about one out of 3 times, when I'm modifying data. How much of the picture is corrupted varies from 0-100%, but it's always a straight cut as shown in the attached screenshot.

This problem happens here at least with digikam 1.4, 1.7, 2.0, 2.5






Reproducible: Sometimes

Steps to Reproduce:
Assign rating by hitting Ctrl-1 or Ctrl-2, ...

It happens "easier" if you do this in a fast sequence, like press Ctrl-1 five times in a second.


Actual Results:  
The image on the screen is partially corrupted as shown in the screenshot. 

The log shows for example (the messages "slotFileRemoved, slotFileDeleted,... were created by me):

digikam(22644)/digikam (core) Digikam::DMetadata::getImageHistory: Loading image history  ""
digikam(22644)/digikam (core) Digikam::DMetadata::setImageTitles: "/home/speicher/gqview/test/DSCN3798.JPG"  ==> Title:  QMap()
digikam(22644)/digikam (core) Digikam::DMetadata::setImageComments: "/home/speicher/gqview/test/DSCN3798.JPG"  ==> Comment:  QMap()
digikam(22644)/digikam (core) Digikam::DMetadata::setImageRating: "/home/speicher/gqview/test/DSCN3798.JPG"  ==> Rating:  3
slotFileClosedAfterWrite:  "/home/speicher/gqview/test/DSCN3798.JPG22644" 
 
digikam(22644)/digikam (core) Digikam::AlbumWatch::rescanDirectory: Detected change, triggering rescan of directory "/home/speicher/gqview/test"
slotFileClosedAfterWrite:  "/home/speicher/gqview/test/DSCN3798.JPG" 
 
digikam(22644)/digikam (core) Digikam::AlbumWatch::rescanDirectory: Detected change, triggering rescan of directory "/home/speicher/gqview/test"
slotFileDeleted:  "/home/speicher/gqview/test/DSCN3798.JPG" 
 
digikam(22644)/digikam (core) Digikam::AlbumWatch::rescanDirectory: Detected change, triggering rescan of directory "/home/speicher/gqview/test"
slotFileMoved:  "/home/speicher/gqview/test/DSCN3798.JPG22644" 
 
digikam(22644)/digikam (core) Digikam::AlbumWatch::rescanDirectory: Detected change, triggering rescan of directory "/home/speicher/gqview/test"
slotFileMoved:  "/home/speicher/gqview/test/DSCN3798.JPG" 
 
digikam(22644)/digikam (core) Digikam::AlbumWatch::rescanDirectory: Detected change, triggering rescan of directory "/home/speicher/gqview/test"
digikam(22644)/digikam (core) Digikam::DImg::load: "/home/speicher/gqview/test/DSCN3798.JPG"  : JPEG file identified
digikam(22644)/digikam (core) Digikam::ScanControllerLoadingCacheFileWatch::slotImageChanged: 27689 "/home/speicher/gqview/test/DSCN3798.JPG"



Expected Results:  
image remains intact
Comment 1 caulier.gilles 2011-12-12 18:27:56 UTC
Can you provide a copy of JPEG image before and after corruption ?

Gilles Caulier
Comment 2 kde 2011-12-12 18:56:17 UTC
The file itself is NOT corrupted, it's just the image displayed which is corrupted. Pressing Ctrl-1 again usually fixes the displayed image.
Comment 3 kde 2011-12-16 18:02:18 UTC
I think I've debugged down now, what the problem is:

If a second modification of a file happens in short time distance to the first modification, then while loading the preview image because of the first modification (previewtask.cpp PreviewLoadingTask::execute(), line 
m_img.load(m_loadingDescription.filePath, this, m_loadingDescription.rawDecodingSettings);

at the same time because of the second modification another thread writes file.jpg$pid, removes file.jpg and moves file.jpg$pid to file.jpg

at the momement of the file remove the previewload thinks loading has finished, while in reality only a part of the image has been read, and thats the part which is displayed then.
Comment 4 Marcel Wiesweg 2011-12-25 14:25:49 UTC
I see the problem. The loading cache's file watch is still based on KDirWatch and needs to be rebased on AlbumWatch/inotify.
I think the solution will create a simplistic LoadingCacheFileWatch which keeps a list and uses the information becoming available in AlbumWatch. I will ping you to test again then.
Comment 5 Marcel Wiesweg 2013-03-21 19:47:15 UTC
With recent versions, we have (in-process) read/write locks which will prevent reading while another thread writes. Testing and confirmation is welcome.
Comment 6 caulier.gilles 2014-01-09 10:51:21 UTC
To kde@schreiber-rolf.de,

Do you see previous message from Marcel ?

Can you test with digiKam 3.x serrie to see if problem still reproducible ?

Gilles Caulier
Comment 7 kde 2014-02-03 17:35:51 UTC
I can confirm, that with 3.1 I cannot reproduce this problem anymore, so I think the fix is working.