| Summary: | many (but not all) tags have been lost after multiple albums facility added | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jonathan Marten <jjm> |
| Component: | Tags-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | marcel.wiesweg |
| Priority: | NOR | ||
| Version: | 1.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.2.0 | |
| Sentry Crash Report: | |||
| Attachments: | Screen shot showing missing images in tag view | ||
|
Description
Jonathan Marten
2010-01-14 23:03:57 UTC
Created attachment 39907 [details]
Screen shot showing missing images in tag view
Which digiKam version you use ? Gilles Caulier Currently: Version 1.1.0 (rev.: 1073781) Using KDE Development Platform 4.4.59 (KDE 4.4.59 (KDE 4.5 >= 20100107)) Which version did you use to convert from your old database (digikam3.db) to the new format (digikam4.db)? No sure when the digikam3 -> digikam4 conversion happened. Would it have been on the first run of digikam from KDE4 trunk, about May 2009 (when I ran into bug 193522)? That was using "0.11.0-svn (rev.: 968562)". Some tags would have been set before this point (in the digikam3 database), more have been added since. No idea currently. You could provide your digikam4.db file for inspection. As requested, databases and config file: http://www.keelhaul.me.uk/kde/digikam4.db http://www.keelhaul.me.uk/kde/thumbnails-digikam.db http://www.keelhaul.me.uk/kde/digikamrc You have two collection defined. One is on the removable storage with partition UUID bfab1e03-ba88-49a6-8c20-6d70537bc07c and on that partition with the relative path /share/photos. The other is manually added to the fixed mount path /share/photos on a hard-wired storage device. You see only the images on the second collection, because the first one is probably not found currently (which is a normal situation for removable storage). Now you should figure out what is the correct collection layout. There were indeed two collections defined in digikam settings (but it wasn't obvious at first glance, because the second was simply labelled "Col0". Not sure where this name came from. Have now changed the settings for a single local collection rooted at /share/photos (I'm assuming that this is the correct one to use for an automounter path). However, after a collection rescan the same tags are still missing. I've done a bit of looking round in the database (with sqlitebrowser) for one of the images that has lost its tags. These are what hopefully are the relevant parts of the tables: Table "Images", rows with "name" = the problem image name: row id album status uniqueHash 6 6 3 b7b8a975... 36168 36462 3 b7b8a975... 66449 66743 3 47473fec... 97020 97314 3 47473fec... 127756 128050 3 47473fec... 158502 158796 3 47473fec... 189242 189536 95 1 47473fec... Table "ImageTags", rows with "imageid" = "id" as above: row imageid tagid 2466 6 1 2467 6 3 2468 6 71 25033 36462 1 25034 36462 3 25035 36462 71 These match the tags as would have been originally set. There are no entries in this table matching any of the other "id"s. The current uniqueHash for the image in question (as calculated in DImgLoader::uniqueHash) is indeed 47473fec... Could the uniqueHash calculation for the image have changed between the time that it was tagged and now? The file modtime on disc has not changed, and is the same as for unaffected images in the same directory. Yes indeed, the hash is different for the obviously identical image in the two collections. I do not remember that the hash calculation changed, maybe the file changed, like after writing metadata. When rescanning, digikam can only copy tags from images which the same hash of course. Difficult situation now, you have tag changes in both versions of each file probably? Have checked the problem image file against backups going back to 2008 (long before I started using the KDE4 digikam). The size, modtime and MD5 are identical to the current version, so nothing has changed in the source file. The uniqueHash is based on the complete image Exif data, plus the first 8Kb of the file, plus the file size. Assuming that the second and third of these have not changed, is there any possibility that the format of the extracted Exif data could have changed? - possibly only in some data-dependent way, which explains why not all files are affected. As you say, a difficult situation. Currently I'm resigned to tagging all of the affected images again, but I'd like to be sure that the work involved will not all be wiped out by some possible problem in future. Will raise a separate bug for that. Since nothing is reproducible, and current digikam creates and saves new tags with no problem, the best option would be to close this bug as WORKSFORME? You are right, the Exif formatting could indeed have changed. It is done by libexiv2. You needed that hash only because you had this problem with broken collections. Normally, if files just stay where they are, you dont need the feature to identify identical files by hash. If it's all right for you we can close as WORKSFORME. Probably this is difficult to solve by SQL. |