Version: 0.10.0-beta3 (using KDE 4.1.1) OS: Linux Installed from: Fedora RPMs In the past, I have successfully used the option to create sub-albums based on date (ISO-date) when importing images from my memory card (through the internal card reader in my laptop). This feature stopped working in version 0.10.0-beta2 (I think), and is still not working in 0.10.0-beta3. If the option to create sub-albums based on date is active, the import process fails with an error message saying "Failed to find album for path '/my/full/album/path'". I have tried to create a new album database, but that doesn't help. If I turn off "Date-based sub-albums" and choose the very same album, the import succeeds. (By the way - the size of my cards as reported in parenthesis in "Import"/"USB Storage devices" and "Card readers" are both "1 TB", although the actual size in both cases is 2 GB)
Marcel, I think this one is database relevant... Gilles
I was able to use the "date-based sub-albums" options again now, after deleting "digikam4.db" from my root album, deleting ~/.kde/config/digikamrc and ~/.kde/apps/digikam/. I then started digikam, selected my root album, chose import, card readers -> my card, selected all photos, checked create date-based sub-albums", and successfully imported all photos. This might have been some glitch when moving from one beta to another beta - maybe there was something invalid in the .db? So, I change resolution to WORKSFORME. I'll report back if the problem reappears. Thanks.
Well, this error came up once more, after uninstalling digikam and then installing version digikam-0.10.0-0.8.beta6.fc11.i386. I did try the workaround (remove .db, digikamrc and the digikam/ folder), but I didn't work. Any suggestions on how to debug this?
Just want to note that if I deselect "Date-based sub-albums", everything works fine (except that I don't get the subalbums that I want of course).
Yes this error is well known, we have been redirecting reports about failure to create date-based subalbums to 175322, so marking this as a duplicate of 175322. *** This bug has been marked as a duplicate of bug 175322 ***