| Summary: | cached image corrupted after modifying metadata | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | kde |
| Component: | Albums-Engine | Assignee: | 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 | |
| Sentry Crash Report: | |||
| Attachments: | corrupted image | ||
Can you provide a copy of JPEG image before and after corruption ? Gilles Caulier The file itself is NOT corrupted, it's just the image displayed which is corrupted. Pressing Ctrl-1 again usually fixes the displayed image. 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. 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. With recent versions, we have (in-process) read/write locks which will prevent reading while another thread writes. Testing and confirmation is welcome. 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 I can confirm, that with 3.1 I cannot reproduce this problem anymore, so I think the fix is working. |
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