Version: 1.1.0, KDE 4.4.00 (KDE 4.4.0) "release 224" (using Devel) Installed from: Compiled sources When renaming a image to an existing image the thumbnail display gets corrupted. Some of the thumbnails do not correspond any more to the images which the thumbnail should be depicting. Running "Tools|Rebuild Thumbnails...|Scan" seems to fix this problem. Renaming an image to an existing, also sometimes crashes digikam. But I think the crash is due to the fact that digikam is crashing once in awhile when additional images are added from another application to a folder which digikam is currently trying to display.
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