Version: 2:1.1.0-1 (using KDE 4.3.4) OS: Linux Installed from: Debian testing/unstable Packages I last fired up digikam last month and it worked fine then. Today I start digikam and it complains that it cannot find my collection in "/media/Pictures" this is weird as I have always used "~/media/Pictures" as my collection. Not much has changed in the interrim, I did do a few safe-upgrades through debian but logs don't show any changes for digikam but some libraries have been updated. Removing this broken collection and re-adding the valid path resolves this warning but as a result a lot of meta-data is lost. Not an acceptable work around. Taking a look at the digikam4.db the "specificPath" column in the AlbumRoots path is set to "/media/Pictures" and not to "/home/USER/media/Pictures." Comparing this entry in the DB to a backup copy of the database from before this issue was encountered reveals that it has not changed! It appears that somehow the interpretation of the specificPath has changed in a way could possibly loose a collection. Work around is opening the database and changing this field as the option to do this in digikam is not presented.
You might want to upgrade to digiKam 1.2.0, that is the newest stable version. On Fri, May 7, 2010 at 10:15 PM, dotCOMmie <bugs@dotcommie.net> wrote: > https://bugs.kde.org/show_bug.cgi?id=236730 > > Summary: Collection path is interpreted differently > Product: digikam > Version: unspecified > Platform: Debian testing > OS/Version: Linux > Status: UNCONFIRMED > Severity: normal > Priority: NOR > Component: general > AssignedTo: digikam-devel@kde.org > ReportedBy: bugs@dotcommie.net > > > Version: 2:1.1.0-1 (using KDE 4.3.4) > OS: Linux > Installed from: Debian testing/unstable Packages > > I last fired up digikam last month and it worked fine then. Today I start > digikam and it complains that it cannot find my collection in > "/media/Pictures" > this is weird as I have always used "~/media/Pictures" as my collection. > Not > much has changed in the interrim, I did do a few safe-upgrades through > debian > but logs don't show any changes for digikam but some libraries have been > updated. > > Removing this broken collection and re-adding the valid path resolves this > warning but as a result a lot of meta-data is lost. Not an acceptable work > around. > > Taking a look at the digikam4.db the "specificPath" column in the > AlbumRoots > path is set to "/media/Pictures" and not to "/home/USER/media/Pictures." > Comparing this entry in the DB to a backup copy of the database from before > this issue was encountered reveals that it has not changed! It appears that > somehow the interpretation of the specificPath has changed in a way could > possibly loose a collection. Work around is opening the database and > changing > this field as the option to do this in digikam is not presented. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. > _______________________________________________ > Digikam-devel mailing list > Digikam-devel@kde.org > https://mail.kde.org/mailman/listinfo/digikam-devel >
Please give the contents of the AlbumRoots table before and after, and the output of "solid-hardware list details".
On 05/15/2010 04:53 PM, Marcel Wiesweg wrote: > https://bugs.kde.org/show_bug.cgi?id=236730 > > > > > > --- Comment #2 from Marcel Wiesweg<marcel wiesweg gmx de> 2010-05-15 22:53:20 --- > Please give the contents of the AlbumRoots table before and after, and the > output of "solid-hardware list details". > There is only one record in AlbumRoots. Before: id: 1 label: (empty) status: 0 type: 1 identifier: volumeid:?uuid=f9ac797c-1967-4036-939e-af81366e0e3e specificPath: /media/Pictures After. id: 1 label: (empty) status: 0 type: 1 identifier: volumeid:?uuid=8d105535-4ef2-4f44-8c45-7cb245fe8167 specificPath: /home/USERNAME/media/Pictures I changed the specificPath, it did initially complain about UUID but I told to override. Not quite sure why this was, possibly while trying to resolve this issue I changed something else. USERNAME is my actual local user name. Is there anything particular in solid-hardware list details that you need as the output is rather long?
Before I see a partition with the UUID f9ac797c-1967-4036-939e-af81366e0e3e and now there is one 8d105535-4ef2-4f44-8c45-7cb245fe8167. The question is which one is correct and in how far your partition layout changed. To make it work for you, I recommend to take the old database and only change identifier and specificPath manually.
On 05/18/2010 08:39 AM, Marcel Wiesweg wrote: > https://bugs.kde.org/show_bug.cgi?id=236730 > > > > > > --- Comment #4 from Marcel Wiesweg<marcel wiesweg gmx de> 2010-05-18 14:39:39 --- > Before I see a partition with the UUID f9ac797c-1967-4036-939e-af81366e0e3e > and now there is one 8d105535-4ef2-4f44-8c45-7cb245fe8167. > > The question is which one is correct and in how far your partition layout > changed. I have 2 disk partitions home and root. 9aea5987... is sda3 f9ac797c... is crypt_LUKS of sda3 which is /home/USERNAME 8d105535... is sda1 the root partition. This partition layout has not changed in several years. The question is how did digikam work before with specificPath of /media/Pictures was it taking this relative to the mount point? > > To make it work for you, I recommend to take the old database and only change > identifier and specificPath manually. > That is what I did. Now the question from all of this. Digikam does not have a way of editing the collections only adding new ones and removing old ones. If digikam had this feature there would not be a need to dabble with the DB to fix this issue. This would be of particular interest for less experienced users. Further more there seems to be dependance between image metadata (comments, rating & etc) and the album. If an album were to break (say recovering from dead disk) there does not seem to be a trivial way of rebuilding this short of manually hacking away at the Album roots table. This seems like a great way for a user to loose important data. It would be nice for digikam on creation of a new album to check for image hashes and compare them to the existing ones (in DB) and relink meta-data based on hashes.
> I have 2 disk partitions home and root. > 9aea5987... is sda3 > f9ac797c... is crypt_LUKS of sda3 which is /home/USERNAME Then the old database was perfectly all right, because f9ac + /media/pictures is on your system obviously /home/USERNAME/media/pictures Something must have changed on your system (broken HAL / Solid) so that this partition is no longer visible to digikam. > 8d105535... is sda1 the root partition. > > > That is what I did. > > Now the question from all of this. Digikam does not have a way of editing the > collections only adding new ones and removing old ones. If digikam had this > feature there would not be a need to dabble with the DB to fix this issue. This > would be of particular interest for less experienced users. All normal use cases should be covered. The occasional bug report here is usually caused by broken platform libraries (HAL / Solid etc.) > > Further more there seems to be dependance between image metadata (comments, > rating & etc) and the album. If an album were to break (say recovering from > dead > disk) there does not seem to be a trivial way of rebuilding this short of > manually hacking away at the Album roots table. This seems like a great way for > a user to loose important data. It would be nice for digikam on creation of a > new album to check for image hashes and compare them to the existing ones (in > DB) and relink meta-data based on hashes. Of course, digikam checks the recorded hash and copies all metadata when it finds an identical file. Unfortunately, we rely on libexiv2 to get hashes over metadata, and the data libexiv2 returned to us changed in the past, so the hashes got different.
On 05/18/2010 11:19 AM, Marcel Wiesweg wrote: >> I have 2 disk partitions home and root. >> 9aea5987... is sda3 >> f9ac797c... is crypt_LUKS of sda3 which is /home/USERNAME > > Then the old database was perfectly all right, because f9ac + /media/pictures > is on your system obviously /home/USERNAME/media/pictures > Something must have changed on your system (broken HAL / Solid) so that this > partition is no longer visible to digikam. > Thank you, I'll see if I can trace the bug there. > >> >> Further more there seems to be dependance between image metadata (comments, >> rating& etc) and the album. If an album were to break (say recovering from >> dead >> disk) there does not seem to be a trivial way of rebuilding this short of >> manually hacking away at the Album roots table. This seems like a great way for >> a user to loose important data. It would be nice for digikam on creation of a >> new album to check for image hashes and compare them to the existing ones (in >> DB) and relink meta-data based on hashes. > > Of course, digikam checks the recorded hash and copies all metadata when it > finds an identical file. > Unfortunately, we rely on libexiv2 to get hashes over metadata, and the data > libexiv2 returned to us changed in the past, so the hashes got different. > That makes sense, looks like convergence of several issues at play here. Is there a way in digikam to rebuild the table of hashes?
> Is there a way in digikam to rebuild the table of hashes? There is no nice UI method for this. You can trigger a full rescan, in this case tags, comments, rating etc. are reread as well (Reread metadata from Images) It's the same effect if you set the modification date in Images to NULL. It could work if you set this modification date to something like 1-1-1970, because a difference in modification date will trigger a "modified file"-rescan, only rereading basic information. Would need to test.
With version 2.0, there will be the possibility to upgrade to a hash which no longer depends on any exiv2 output, only on direct file contents. Please feel free to discuss any remaining issues here, it's just I cannot see anything left to do from our side for this problem.