Version: 0.7.0 (using KDE KDE 3.3.2) Installed from: Gentoo Packages Compiler: gcc 3.3.4 OS: Linux I renamed an album with a couple of hundred images in it from 'Family' to 'Family Photos'; instead of just changing the album name, changing the directory name, and updating the sqlite DB, digikam recreated all the image thumbnails for every photo. This took a loooong time. Bug: renaming an album shouldn't take longer than a directory rename and an SQL 'UPDATE" query.
on directory renaming digikam does exactly that: rename folder, update the db with the new album name and done. what happens is that the image thumbnails are stored in ~/.thumbnails/normal and ~/.thumbnail/large (freedesktop standards) and these thumbnails names are generated and encoded from the full url of the file. for eg, file:///home/john/Pictures/Album/A.jpeg may have a thumbnail named as ff8938903820382.png . now digikam is not smart enough (yet) to rename the thumbnails for each of the files in the album. but neither is konqueror or any of the other image management programs on linux. i think you are under the (mis)impression that digikam stores the thumbnails in the database. i will file this report as a wishlist once i hear back from you
Yes, that makes sense. Wishlist it is.
This also happens when you move photos from one album to another, and perhaps when you do other things..
This also happens when one enabled Tag Filters in album view mode (see related bug 131382). How can this be construed as a wishlist? This is definitely a bug in my humble opinion. If you have 10 memory-cards worth of pictures in your collection (20GB), and you rename your albums, then it'll take a full one hour of your time hitting page-down while waiting for thumbnails to regenerate (since generate-thumbnails-for-album functionality is still being implemented).
This also happens when the "Menu: Image > Adjust Date & Time" is used.
I think this is unreasonable to classify as a wishlist; this is clearly a serious bug. Look at the votes even!
#131382 was a serious bug, and is fixed now. Comment #5 is a different issue, the modification date is used as a sign that the file has changed and the thumbnail needs to be regenerated. The regenerate-all-thumbnails is now implemented. All considered, what is explained by Renchi in #1 two years ago is a missing feature, and that's clearly a wishlist entry ;-)
> All considered, what is explained by Renchi in #1 two years ago is a missing feature, and that's clearly a wishlist entry ;-) I strongly disagree; it seems more like a poorly-implemented feature rather than a missing feature (no offense). Even if it was a wishlist entry, it seems trivial to fix: Comment #1: > what happens is that the image thumbnails are stored in ~/.thumbnails/normal and ~/.thumbnail/large (freedesktop standards) and these thumbnails names are generated and encoded from the full url of the file Solution: Simply name the thumbnail after a hash of the image data... (or a hash of a random subset of the image data, if speed is an issue). You can keep the thumbnails in the database if you want, as a speed optimization. This has the following nice properties: 1) thumbnails never need to be regenerated unless the image changes 2) thumbnails correspond to exactly what they should correspond to: a the raw image data (not some -- in my humble opinion -- ridiculous notion that an image is defined by a url and a date; an image is defined by its data).
Maybe digikam should do an iphoto-like approach, i.e. storing images in $whereever/$year/$month/$day and organizing albums as folders with symlinks to actual images. this way the url to the actual file never changes when you reorganize your files. Additionally this change would be transparant as all other tools would see the same layout as now (folders, subfolders, ..) - not even to speak of the possibility to have the same image in multiple albums without a copy. other way would be: use thumblocal, as defined in the freedesktop proposal.
>other way would be: >use thumblocal, as defined in the freedesktop proposal. digiKam is already full compliant with freedesktop proposal since 0.7 release (:=))). We use a kioslave for that. Gilles Caulier
*** Bug 126111 has been marked as a duplicate of this bug. ***
I would happy, that would be solved...
Do I understand things correctly, that for the following cases - renaming an album - renaming a file - moving a file from one album to another one could simply do for each involved image: mv ~/.thumbnails/normal/${hashname_for_old_location}.png \ ~/.thumbnails/normal/${hashname_for_new_location}.png (and the same for ~/.thumbnails/large)? Question: presently, if thumbs are re-created for the new location, does it mean that the old thumbs still lie around? This sounds like it could use up quite some disk space over time ... (Also, when deleting files, are the thumbs deleted as well?)
Arndt, you are right in your assumption. The answer to your question is "yes".
I've never looked at the source of digiKam before, but it looks like any operation like rename marks the album as dirty (adds it to dirtyAlbums). Presumably some process later checks dirtyAlbums and calls digikamthumbnail to refresh everything in them (including thumbnails). I can't think of a way that this process would know how to do this. The thumbnail generator doesn't know the old URL, so it can't just use mv.
*** Bug 191633 has been marked as a duplicate of this bug. ***
This has been fixed some weeks ago... Please try the latest SVN build if possible. Andi
We should close this one, it is fixed in 0.10 (maybe even 0.9.5) and all latest versions. Andi