Summary: | Rename image and overwriting existing messes up the thumbnail display | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Andyfloe <Andreas.Floeter> |
Component: | Thumbs-Image | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | caulier.gilles, marcel.wiesweg, mrintala43 |
Priority: | NOR | ||
Version: | 1.1.0 | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: | 2.6.0 | |
Attachments: |
highlighted thumbnail does not correspond to image
After renaming some files are without suffix |
Description
Andyfloe
2010-02-28 12:01:32 UTC
What do you mean by "corrupted" - is it what you say in the next sentence, that the thumbnails show a different image? Which image is shown? If there is a crash, give us a backtrace, unless it is one of the crashes which are already reported. Created attachment 41213 [details]
highlighted thumbnail does not correspond to image
Yes, "corrupted" means that the map of thumbnails does not correspond to the images which actually should be shown. I have added a screenshot which should make it a little clearer. Furthermore, I don't know if the crashes provoke it or if there is something else going wrong, but I found that the renaming somehow must have failed for some images, see "digikam_image_naming_problem_20100228.txt". Created attachment 41214 [details]
After renaming some files are without suffix
SVN commit 1098429 by mwiesweg: Do not exif-rotate a second time in editor - previews are rotated in the cache, and in the case of full-size preview of a JPEG, this data will be reused for the image editor. CCBUG: 228869 M +6 -1 dimginterface.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1098429 Sorry, wrong bug How did you rename the images, manually? (context menu, F2) Can you reproduce when renaming a single image? Does the list of images without suffix correspond to those images which show the wrong thumbnail? I have been on a business travel there my feedback is a little delayed. Sorry about that. I scanned slides. After all have been processed I fire up digikam. Then I do a quality check and possibly re-scan some slides. The new slide might have the name e.g. "dfd20100227_0086.jpg". I select it and with right click I choose operation "rename" which would be F2. The slide which did not meet my quality expectations might be "dfd20100227_0015.jpg". Therefore I rename "dfd20100227_0086.jpg" to "dfd20100227_0015.jpg" and knowledge that I overwrite it. During this operation it might be that I already re-scan another slide which goes to the same folder with name e.g. "dfd20100227_0086.jpg". It is not happening all the time that a thumbnail of the image in this folder gets corrupted by this kind of operations. But it is not necessarily the image which I renamed which has the wrong thumbnail associated to it. (In reply to comment #7) > How did you rename the images, manually? (context menu, F2) > Can you reproduce when renaming a single image? > Does the list of images without suffix correspond to those images which show > the wrong thumbnail? Marcel, I guess renaming of files is not working correctly, see this line here: http://lxr.kde.org/source/extragear/graphics/digikam/digikam/imageviewutilities.cpp#111 We are creating the url for updating the thumbnails and other information from the new (renamed) url, this can't work, or am I wrong here? This might also be related to https://bugs.kde.org/show_bug.cgi?id=206866 Andi Yes, interesting observation ;-) I think the intention was not to clean up the thumbs database but to force regeneration of the thumbnail in case an image was overwritten. This is probably not needed, may even lead to unnecessary work done (but the LoadingCacheInterface call may be needed, in case of overwriting). You are thinking along the line of cleaning up a thumbnail reference by file path after a rename. Yes, we may indeed want to remove the file path entry in the thumbs db, perhaps even already before doing the move. But the unique hash reference should be kept, a rename does not change the contents. In case of renaming: There is a fix in SVN for this issue: After renaming images, go to Tools->Rebuild Thumbnails->Scan. This will recreate all updated / missing thumbnails. It works fine here, but a automatic solution would be better of course. In case of overwriting the images I don't think the fix does help. We definitely need to check more in deep for the problems described here. I have also noticed the "wrong thumbnail showing" bug (happened still in 1.7.0, have not yet noticed it on 1.8.0). However, in my case the problem shows with files where images have not been renamed or overwritten. For example, I had an image with name "090625_115609-d40.tif" (i.e., a unique name with datestamp and camera model). It's thumbnail has been replaced by the thumbnail of another image in a different directory and definitely with a different name. It seems to me that this may have happened after I moved the other image (not the corrupted one) to a new directory. However, neither of those images was ever renamed, and the image with the corrupted thumbnail was older than the wrong thumbnail it was given. Matti Andy, Matti, This file still valid using digiKam 2.4 ? Gilles Caulier On Monday 19 December 2011 14:57:54 Gilles Caulier wrote:
Hello Gilles,
At the moment I can not answer you question, because I am currently using
openSUSE 11.4 and for this version of openSUSE the version 2.4 is not
provided. I am planning to upgrade to openSUSE 12.1 in the next couple weeks.
What I can say is that the disrupted thumbnails were still present in version
2.3 when images were placed in a folder which was currently visible.
Best Regards,
Andreas
> https://bugs.kde.org/show_bug.cgi?id=228869
>
>
>
>
>
> --- Comment #13 from Gilles Caulier <caulier gilles gmail com> 2011-12-19
> 13:57:53 --- Andy, Matti,
>
> This file still valid using digiKam 2.4 ?
>
> Gilles Caulier
Unfortunately the problem manifests randomly, so it's very difficult to know if it's been fixed or not. But I haven't noticed any corrupted thumbnails for some time, so let's hope it's been fixed. :-) Matti ok, i close it. Re-open if necessary... Gilles Caulier |