Bug 305104

This is a binary compatibility issue with digiKam KIO slave on your system : It's typically a packaging problem with dependencies...

Update digiKam to last 2.8.0 and try again...

Gilles Caulier

I have the same issue with Version 2.8.0.
I use the MYSQL database, in which alle the images are listed for the folder in which I have the problem (with jpg and JPG extensions which corresponds to the file name extension) . Also they are all present in the folder (as I see in a terminal), but the files with JPG don't show up in the Album preview for this folder

In other folders, where I have images with upper case JPG ending, the images show up, so I don't know what's different in this specific folder.

I Use:
digikam/quantal uptodate 4:2.8.0-0ubuntu1
digikam-data/quantal uptodate 4:2.8.0-0ubuntu1
libkface-data/quantal uptodate 1.0~digikam2.8.0-0ubuntu1
libkface1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1
libkgeomap-data/quantal uptodate 1.0~digikam2.8.0-0ubuntu1
libkgeomap1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1
libkvkontakte1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1
libmediawiki1/quantal uptodate 1.0~digikam2.8.0-0ubuntu1

Did you edit them with the digikam image editor, hiding the original?

(In reply to comment #3)
> Did you edit them with the digikam image editor, hiding the original?

I guess you are refering to the non-destructive image manipulation. I didn't edit the picture.
I did some further test, an in a new image folder it is no problem to have jpg/JPG files. 
I guess there is something mixed up in the Database, also I could not find differences in the images / imageinformation tables in the pictures showing up or  not showing up. However, when I moved all images from the folder to another place (on a terminal), and then back, the missing images reappeared. In the "image" Table they have a new id
Still, I have the problem that I don't know if images in other folders are not shown our found by refreshing.

I'm having the same problem with some JPG images not showing up in Digikam.  The images in question used to show up, because they have tags that I added using Digikam.
digiKam Version 2.5.0 Using KDE Development Platform 4.8.5 (4.8.5)
Ubuntu 12.04.1 LTS
Unity 5.18

If I check: Settings → Configure digiKam → Editing Images → Always show original images, the missing images appear.  The Image HIstory bar shows a mess of Derived Images and Identical Images that are neither derived nor identical.

Is there a pattern how to reproduce this situation? Do you remember how you saw this first?

Unfortunately, I don't know when or how the problem started.  I just noticed the images were missing in Thumbnails view, but I'm sure the problem went unnoticed for awhile.

To all in this file :

This problem still exists with digiKam 3.5.0 ?

Gilles Caulier

Have not see the problem lately and I have been working with local and 
network files so I think the bug has been killed.

Thank You

Mac





On 13-12-04 09:30 AM, Gilles Caulier wrote:
> https://bugs.kde.org/show_bug.cgi?id=305104
>
> --- Comment #9 from Gilles Caulier <caulier.gilles@gmail.com> ---
> To all in this file :
>
> This problem still exists with digiKam 3.5.0 ?
>
> Gilles Caulier
>

The problem still exists with:
Qt: 4.8.6
KDE Development Platform: 4.14.9
digiKam: 4.6.0


by checking: Settings → Configure digiKam → Editing Images → Always show original images, the missing images appear, as previously described.

I have the problem too. Interestigly, the "Table" view mode is not affected, only thumbnails and preview.

The "versioning" sidebar also show some pictures with tons of "identical images" that are not identical _at all_. Like an Aquarium image from Akademy 2015 daytrip is identical to a camp file from Randa.

Encountered this problem in digikam Version 3.5.0 with KDE 4.13.3 on Ubuntu 14.04.05 LTS.

Status of this bug is resolved as  FIXED in Version 4.0.0 but  Juraj #c11said on 2015-07-13 15:53:34 UTC
that the problem still exists with digiKam: 4.6.0.

Any news about that?

How do I fix the "mess of Derived Images and Identical Images that are neither derived nor identical"? Is this possible to do within digikam? Or do I have to use a command line tool to remove the non identical images? And how do I do that?

Thank you very much!

I did the following, awhile back, on linux.  Not sure what may have changed in the interim, and I can't speak for non-linux platforms, so YMMV.  FIRST, BACK UP YOUR DATABASE!

Make sure digikam is not running.  Go into digikam4.db using sqliteman and drop and re-created the imagerelations table. Re-start digikam.  I don't remember if there's a tool that you have to run manually, or if it runs automatically, but it should recreate correct image relations.  May take awhile depending on the size of your albums.

I hope this helps.  Please post your results for others.

Given I just **deleted** the database and started from scratch and still have the issue, I would argue that the bug isn't fixed, it never was and it still fully there as of Digikam 5.1

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. 

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”.

What I tried to fix the problem:
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. The images still have the wrong identical images assigned. The cleared table is still empty. 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.

Tools -> Maintenance -> Sync Metadata and Database -> Sync direction: From database to image metadata 
seems to be useful, but in the settings no checkbox looks like the right one.

Reading bug 323210#c4 again: 
“Dropping the relations table has no side effects, you just lose relations. Locating identical images is not based on the relations table, it's based on file hash and file size“ lead me to look closer into the database and I figured out, that all/most of the images in that dropbox folder had the same 
Exif.Photo.ImageUniqueID which were also stored in the database in the table ImageHistory in column uuid.
These photos were taken by: 
Exif.Image.Software : N9005XXUBMI7
Exif.Image.Model : SM-N9005
Exif.Image.Make  : SAMSUNG

Finally I was able to correct the database.
What I did trying to figure it out (using digikam 4.12 on Ubuntu 16.04): 
I set up a new digikam collection with only the images from dropbox and dumped the sqlite database.  
Then I removed the ImageUniqueID from the images were it was not unique with 
exiv2 -M'del Exif.Photo.ImageUniqueID'  /home/user/dropbox/images/*.jpg
Then I removed the database-file to let digikam create it again and dumped it, too. (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. 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. 
With this information I were able to edit my original digikam database and now everything works right.

Follow these steps to solve the problem:
0. Close digikam and make a bakup of the collection database. Make sure to have sqlite3 or SQLiteManager for Firefox or a similar tool available to check and edit the database.

1. Identifying photos which have identical values in: Exif.Photo.ImageUniqueID This is easily done by 
SELECT *,  COUNT(*) as c FROM ImageHistory GROUP BY uuid HAVING 	c > 1 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 AND history IS NULL ORDER BY c DESC
)
I removed the entries with unique uuids after copying the imageids to a file for further usage.

2. Remove the ImageUniqueID from the images where it was not unique with 
exiv2 -M'del Exif.Photo.ImageUniqueID'  /home/user/dropbox/images/*.jpg

3. Then DELETE the offending entries in the tables ImageRelations and ImageTags using the imageids from step 1. (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.)

For example I used queries like 
SELECT imageid, name FROM ImageTags LEFT JOIN Images ON Images.id = ImageTags.imageid WHERE name LIKE '20160624%.jpg'  AND  tagid = 18
to check the database for images of a certain name and the corresponding tagid for "Original Version".
Look in the table Tags for tags containing "version" in the name to find out the right tagid:  
SELECT * FROM Tags WHERE name LIKE'%version%'

4. Close the database and start digikam again. That's it!

If i follow your explaination the dropbox uploader patch file with UUID.

Which dropbox tool do you use exactly ?

Gilles Caulier

I'm sorry for my writing, English is not my native language. 
So I don't think that Dropbox is causing that error by adding or changing Exif.Photo.ImageUniqueID . I think some smart phone cameras create these. I just got these photos taken by others with their smart phone via Dropbox. I use the native Dropbox client from https://www.dropbox.com/install for Ubuntu 64bit. It says it has version 9.4.49.

I do found other images in my database which I didn't received via Dropbox with not unique Exif.Photo.ImageUniqueID values. They were six characters long so I could select them with: 
SELECT uuid, name, make, model FROM ImageHistory 
LEFT JOIN Images ON Images.id = ImageHistory.imageid
LEFT JOIN ImageMetadata ON ImageMetadata.imageid = ImageHistory.imageid
WHERE uuid LIKE '______'

(I don't no how to select entries with an uuid with less then 64 characters.)

It turned out that all of these were taken by a Samsung GT-I9300 , Exif.Image.Software  I9300XXUGNG3 or Samsung GT-I9400 (Software I9100XWLSD).

Can digikam not just ignore the Exif.Photo.ImageUniqueID value? Most images in my collection don't have it.

I think Exif UUID is used to register versionning UUID in Database, if this tag exist in image.

To get UUID from metadata :

https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdmetadata%2Fdmetadata.cpp

... at line 966

The use cases of this method :

https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdatabase%2Fitem%2Fimagescanner.cpp

... at lines 981 and 1006.

Gilles Caulier

Ok, I see. 
It looks like that the test in
https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdmetadata%2Fdmetadata.cpp ... at line 966
 if (!exifUid.isEmpty() && !exifUid.startsWith(QLatin1String("00000000000000000000")))
is not sufficient, as I have values from Exif.Photo.ImageUniqueID with only 6 characters in the database as ImageHistory.uuid .