Bug 374302

Created attachment 103067 [details]
Metadata-View

Created attachment 103068 [details]
Map

Created attachment 103069 [details]
Geolocation-Editor

Not reproducible here with compiled digiKam 5.4.0. Image is taken in Austria and visible in GoogleMaps :

https://www.flickr.com/photos/digikam/31591333580/in/dateposted-public/

Gilles Caulier

Same for AppImage Linux Bundle 5.4.0, which use Exiv2 0.26:

https://www.flickr.com/photos/digikam/31848591061/in/dateposted-public/

Gilles Caulier

Thanks for the response,

I have no idea how to help you reproduce the error, so I'll describe what else I have tried and hope that somebody else also has this problem.

I have copied the image and modified the geolocation with the geolocation-tool (which is working correctly) so now there are other metadata.

➜  ~/Bilder exiftool b.jpg | grep GPS
GPS Version ID                  : 2.0.0.0
GPS Altitude Ref                : Above Sea Level
GPS Map Datum                   : WGS-84
GPS Altitude                    : 249 m Above Sea Level
GPS Latitude                    : 48 deg 25' 14.27" N
GPS Latitude Ref                : North
GPS Longitude                   : 15 deg 37' 7.84" E
GPS Longitude Ref               : East
GPS Position                    : 48 deg 25' 14.27" N, 15 deg 37' 7.84" E

But the issue remains.

The components information is also showing Exiv2 0.26 (as I have downloaded the appimage just before testing).
Exactly the same happens with 5.3.0

I'll report if I have an idea, what could be wrong.

Can you create a fresh account on your computer, start digiKam and import geolocated files in database ? Just to see if problem is reproducible with a clean database...

Gilles Caulier

I now tested again, I found out why it is working for you.
I am using a MySQL database. 
At first I created a new MySQL database but I got the same problem.
Then I tried SQLite and it is working correctly. So I looked into the MySQL-Database and found that the coordinates are there:

mysql> SELECT * FROM `ImagePositions` where imageid = 39891;
+---------+-----------------+--------------------+-----------------+--------------------+----------+-------------+------+------+----------+-------------+
| imageid | latitude        | latitudeNumber     | longitude       | longitudeNumber    | altitude | orientation | tilt | roll | accuracy | description |
+---------+-----------------+--------------------+-----------------+--------------------+----------+-------------+------+------+----------+-------------+
|   39891 | 48,25.23788333N | 48.420631388888886 | 15,37.13064167E | 15.618844027777778 |      249 |        NULL | NULL | NULL |     NULL | NULL        |
+---------+-----------------+--------------------+-----------------+--------------------+----------+-------------+------+------+----------+-------------+
1 row in set (0,01 sec)

So the problem seems to be in the part in the map-module that tries to fetch the coordinates.

I hope this helps.

The problem is not to reproduce here with a new internal MySQL database.

Maik

(In reply to Maik Qualmann from comment #9)
> The problem is not to reproduce here with a new internal MySQL database.
> 
> Maik

I forgot to mention: I am using the external MySQL-Server from debian testing.

> ➜  ~ mysql --version
> mysql  Ver 14.14 Distrib 5.6.30, for debian-linux-gnu (x86_64) using  EditLine wrapper

I tried the internal MySQL-Server with the same MySQL binary (/usr/sbin/mysqld) and got the same problems.

Is there a way to view the SQL-queries to find out why "SELECT * FROM `ImagePositions` where imageid = 39891;" is returning the coordinates, but the query in digikam isn't?

Result of additional testing:

I created a virtual machine with ubuntu 16.10 and installed MySQL 5.7 and later mariadb 10.0.28.
Furthermore I created a new user to start a fresh digikam.

With both databases (as an external MySQL server) I can reproduce the error.

No change with 5.5.0. 
Is there any way I can help? Is there a verbose log which logs the MySQL-queries?

Git commit 300aea9d80091ccf4577b3fb140bdafaa8dcd7e1 by Maik Qualmann.
Committed on 07/03/2017 at 22:07.
Pushed by mqualmann into branch 'master'.

remove wrong code to add image position in ImageScanner::copiedFrom()
Related: bug 376933
FIXED-IN: 5.5.0

M  +2    -1    NEWS
M  +0    -5    libs/database/item/imagescanner.cpp

https://commits.kde.org/digikam/300aea9d80091ccf4577b3fb140bdafaa8dcd7e1

The problem is not reproducible here. I also do not think it is a MySQL problem. Can you reproduce the problem with a SQLite DB?

Maik

If I remember correctly, it worked with a sqlite-database.

I'll test it again with a new user account and empty databases

I think I have found out why you can't reproduce it:

I have dropped the database, recreated it and started digikam for the first time (so it creates the tables)

Then I changed to another database (digikamtest2), created it and restarted digikam again. But this time I started it with 

LANG=C /opt/digikam-5.5.0-01-x86-64.appimage

so that the error messages would appear in English (my system is in German). Oddly the map did work this time. I created a diff of this two databases and it seems like the only difference is the 'Locale'-Setting which is set to 'UTF-8' every time it doesn't work.

< -- Datenbank: `digikamtest2`
---
> -- Datenbank: `digikamtest`
474,477c474,477
< ('databaseUUID', '{118c6a08-34af-41ec-b894-8433443ef1ab}'),
< ('Locale', 'UTF-8'),
< ('DeleteRemovedCompleteScanCount', '2'),
< ('Scanned', '2017-03-08T19:59:14');
---
> ('databaseUUID', '{bf7cb542-4d29-4ff8-b4e2-dca5025dff9c}'),
> ('Locale', 'US-ASCII'),
> ('DeleteRemovedCompleteScanCount', '3'),
> ('Scanned', '2017-03-08T19:57:15');

Is it possible that the error has to do with the handling of the locale?

Now that the bug is reproducible is it maybe possible for you to look into it again? This is the only think that bugs me with digikam.

Thanks for the great software,

Lukas

I could also not reproduce the problem by changing the locale.

Maik

Maik,

Why the locale will influence the geolocation stuff here ?

Gilles Caulier

I can't test it at the moment, but maybe it is  because I am using German (DE_AT.UTF). Could it be because of a difference in decimal comma (e.g. comma instead of dot)

Which database do you use MySQL or MariaDB? The tables longitudeNumber and latitudeNumber have which field type STRING or REAL?

Maik

I just checked it: I am using MariaDB 10.1.23 on Debian Stretch.

MariaDB [digikamtest]> SELECT * FROM ImagePositions;
+---------+-----------------+--------------------+-----------------+--------------------+----------+-------------+------+------+----------+-------------+
| imageid | latitude        | latitudeNumber     | longitude       | longitudeNumber    | altitude | orientation | tilt | roll | accuracy | description |
+---------+-----------------+--------------------+-----------------+--------------------+----------+-------------+------+------+----------+-------------+
|       1 | 48,25.23788333N | 48.420631388888886 | 15,37.13064167E | 15.618844027777778 |      249 |        NULL | NULL | NULL |     NULL | NULL        |
+---------+-----------------+--------------------+-----------------+--------------------+----------+-------------+------+------+----------+-------------+
1 row in set (0.00 sec)

MariaDB [digikamtest]> describe ImagePositions;
+-----------------+----------+------+-----+---------+-------+
| Field           | Type     | Null | Key | Default | Extra |
+-----------------+----------+------+-----+---------+-------+
| imageid         | int(11)  | NO   | PRI | NULL    |       |
| latitude        | longtext | YES  |     | NULL    |       |
| latitudeNumber  | double   | YES  |     | NULL    |       |
| longitude       | longtext | YES  |     | NULL    |       |
| longitudeNumber | double   | YES  |     | NULL    |       |
| altitude        | double   | YES  |     | NULL    |       |
| orientation     | double   | YES  |     | NULL    |       |
| tilt            | double   | YES  |     | NULL    |       |
| roll            | double   | YES  |     | NULL    |       |
| accuracy        | double   | YES  |     | NULL    |       |
| description     | longtext | YES  |     | NULL    |       |
+-----------------+----------+------+-----+---------+-------+
11 rows in set (0.00 sec)

Another insight:
I just started Digikam with LANG=C /opt/digikam-5.6.0-01-x86-64.appimage and it converted the digikam locale to 'US-ASCII' and geodata worked.

But then I started it with LANG=de_AT /opt/digikam-5.6.0-01-x86-64.appimage (notice that my system locale is de_AT.UTF8) and digikam converted the database back to UTF-8, but started in English and it still worked. 

Finally I started it with LANG=de_AT.UTF8 /opt/digikam-5.6.0-01-x86-64.appimage and now it started in German and it didn't work anymore. 

I think it doesn't have much to do with the database, but some part of Digikam (KDE? Qt?) is interpreting something wrong with a German locale set.

Strangely, I can actually reproduce the problem with the AppImage. But not with my compiled and installed version of digiKam.

Maik

Maik,

AppImage bundle use a bash script to start the application, depending of CLI option passed by user.

The script can miss some rules to fix this problem.

The script is here :

https://cgit.kde.org/digikam-software-compilation.git/tree/project/bundles/appimage/data/AppRun

To tune this script without to re-build whole AppImage, it's very simple. 
Download last appImage bundle, and mount it in local. In fact AppImage is an ISO9660 drive loaded in memory. As root :

#mkdir ./test.appimage
#mount ./digikam-5.6.0-01-x86-64.appimage ./test.appimage
mount: /dev/loop0 is write-protected, mounting read-only
#ls ./test.appimage
AppRun*  digikam.desktop*  digikam.png  usr/

As the bundleis mounted as read only, just copy the whole directory somewhere in your home dir and edit AppRun script. To start application, run this script as well...

Magic no ?

Gilles Caulier

Hi, sorry it took so long for an answer, but the last month was quite stressful.

I am not sure how editing the AppRun bash script will solve this.

Hardcoding the LANG env doesn't fix the issue, but only makes it reproducible.

In the meantime I have found out that if I start digikam with LANG=de /opt/digikam-5.6.0-01-x86-64.appimage
(which is an invalid locale) it starts with an English user interface (because of that the geodata is working correctly), but it doesn't trigger the "do you want to convert the database to ASCII" dialog (I am afraid that will create problems as many of my photos include special characters).

With next 5.8.0 release Mysql support have been well improved and a lots of
bugs fixed.

Please test with pre release 5.8.0 bundles that we provide and give us a
feedback

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier

Now that Bug 387958 is solved, I have tested this again, but nothing did change since 5.7

Nothing did change regarding the bug, but I switched to the debian package (not sure why I was using the appimage as I am using KDE) and it doesn't have the issue.
So for me this issue is solved.