Version: 0.11.0-svn (using 4.2.00 (KDE 4.2.0), Arch Linux) Compiler: gcc OS: Linux (i686) release 2.6.28-ARCH When I move single folder albums around, their thumbnail is kept when displayed in the new location. But when I move nested albums around, I loose ALL my thumbnails in this album hierarchy. For example: A B C |- D |- E Moving album D -> A or A -> B works fine, also B -> E is ok. But if I move C -> A for example, all album thumbnails are gone, so I need to set them again for folder C, D and E. Andi (and again, valid for 0.10)
(In reply to comment #0) > But when I move nested albums around, I loose ALL my thumbnails in this album > hierarchy. Must be: "... I loose ALL my ALBUM thumbnails in this album hierarchy..." BTW this is a big problem, I moved a nested hierarchy of 35 albums around, now I can set all the thumbnails again. We should try to fix this for 0.10 release, it can be very annoying.
The same is true when moving around collections, but then it doesn't matter if single or nested album, they get destroyed all the time.
Look at thumbnailcreator.cpp and thumbnailbasic.cpp in libs/threadimageio. According to freedesktop's specification, the name of the thumbnail is computed from an MD5 hash of the file path - from the full file path. As far as I know no thumbnails are ever moved when a file is moved, so any change in the file paths would cause thumbnail recomputation. Or is there a piece of code somewhere that I am missing? We can of course implement a thumbnail renaming functionality. Would need to be triggered from dio.cpp. After a double check that the move operations from within digikam all use a digikamalbums:// url it could be put into the copy and rename methods of the ioslave. When a move is done from outside digikam, we will recognize the files by checksum and could use that information as well. (This includes the case above). Perhaps this is the better method. But we need to build a bridge from the collection scanner to a place that knows about thumbnails
But why is it working when I move none nested albums? To make it clear again: I'm talking about the folder / album thumbnails, not the file thumbnails. They are always recomputed (when moved), which is logical.
Ah, album thumbnails. That's different ;-)) Will look into that the next days. That's really a bug then which needs to be solved.
See also: https://bugs.kde.org/show_bug.cgi?id=94562 If I remember correctly, the thumbnails also store the location of the original image in their metadata. So of one moves the original images around, and renames the thumbs accordingly, the meta-info has to be corrected as well.
SVN commit 931901 by mwiesweg: Fix recording hints for the copy or move of children of the moved album. The dst path was not adjusted properly. CCBUG: 185317 M +6 -1 scancontroller.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=931901
It seems to be fixed... But there is another problem with thumbnails (in iconview), I will open another report for that. Andi
Marcel, will you backport this to 0.10 or is it too risky? Andi
SVN commit 932477 by mwiesweg: Backport: Fix recording hints for the copy or move of children of the moved album. The dst path was not adjusted properly. CCBUG: 185317 M +6 -1 scancontroller.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=932477
I will re-open this one because it is also true if you rename a parent folder. All album thumbnails of the children will get lost when renaming the parent. Andi
SVN commit 938132 by mwiesweg: When renaming the parent album, the parentPath of child albums need to be adjusted. Then renaming in db is really done with a new name, not with the same name again. CCBUG: 185317 M +4 -1 albummanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=938132
SVN commit 938145 by aclemens: backport: When renaming the parent album, the parentPath of child albums need to be adjusted. Then renaming in db is really done with a new name, not with the same name again. BUG: 185317 M +4 -1 albummanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=938145