I use the native Dropbox client from for Ubuntu 64bit. I just got these photos taken by others with their smart phone via Dropbox. I think some smart phone cameras create these. So I don't think that Dropbox is causing that error by adding or changing. I'm sorry for my writing, English is not my native language. Close the database and start digikam again. SELECT * FROM Tags WHERE name LIKE'%version%'Ĥ. Look in the table Tags for tags containing "version" in the name to find out the right tagid: To check the database for images of a certain name and the corresponding tagid for "Original Version". SELECT imageid, name FROM ImageTags LEFT JOIN Images ON Images.id = ImageTags.imageid WHERE name LIKE '20160624%.jpg' AND tagid = 18 (Because I edited some images I couldn't simply delete all entries claiming to be an "Original Version", so I looked through them manually, comparing the name or tagid.) Then DELETE the offending entries in the tables ImageRelations and ImageTags using the imageids from step 1. Remove the ImageUniqueID from the images where it was not unique withģ. I removed the entries with unique uuids after copying the imageids to a file for further usage.Ģ.
SELECT *, COUNT(*) as c FROM ImageHistory GROUP BY uuid HAVING c > 1 AND history IS NULL ORDER BY c DESC (I also saw only photos affected which have no history entries: SELECT *, COUNT(*) as c FROM ImageHistory GROUP BY uuid HAVING c > 1 ORDER BY c DESC Identifying photos which have identical values in: This is easily done by Make sure to have sqlite3 or SQLiteManager for Firefox or a similar tool available to check and edit the database.ġ. Close digikam and make a bakup of the collection database. With this information I were able to edit my original digikam database and now everything works right.Ġ. By that I figured out that the table ImageTags is also involved: Images wrongly identified as identical to others have the tagid which has the name "Original Version" in tags table. (Now all images were already shown and no wrong images were assigned as identical.) Then I looked at the diff of the two database dumps. Then I removed the database-file to let digikam create it again and dumped it, too. Then I removed the ImageUniqueID from the images were it was not unique withĮxiv2 -M'del ' /home/user/dropbox/images/*.jpg
I set up a new digikam collection with only the images from dropbox and dumped the sqlite database. What I did trying to figure it out (using digikam 4.12 on Ubuntu 16.04):
Seems to be useful, but in the settings no checkbox looks like the right one.įinally I was able to correct the database. Tools -> Maintenance -> Sync Metadata and Database -> Sync direction: From database to image metadata So these information has to be stored elsewhere - but where? I couldn't find a corresponding XMP entry in these images with neither exiv2 nor exiftool. The images still have the wrong identical images assigned. I deleted the wrong data sets (I had 21 entries for one subject with different objects, type 1 and the same objects also for another subject - 42 wrong entries in total) and later cleared the table ImageRelations - also with no success. It looks like bug 323210 is a duplicate of this one, maybe someone with the permission can set this and maybe also edit the summary of this bug to something like “Digikam does not show some jpg images because assigned wrong identical/derived images”. I forgot to say in my comment 13 that I encountered that problem in only one album which is a folder synced with the Dropbox client after editing an image.