Created attachment 103066 [details] The testimage Hello, I am using the latest Appimage (5.4.0) 64bit with Debian Testing (Gnome). Digikam seems to have Problems detecting Geodata. The testimage (Attachment) was made on an Android Phone and seems to have a GPS Position: ➜ ~/Bilder exiftool a.jpg | grep GPS GPS Date Stamp : 2016:12:29 GPS Altitude Ref : Above Sea Level GPS Longitude Ref : East GPS Img Direction : 58 GPS Processing Method : ASCII GPS Latitude Ref : North GPS Img Direction Ref : Magnetic North GPS Time Stamp : 19:03:03 GPS Altitude : 249 m Above Sea Level GPS Date/Time : 2016:12:29 19:03:03Z GPS Latitude : 48 deg 25' 14.27" N GPS Longitude : 15 deg 37' 7.84" E GPS Position : 48 deg 25' 14.27" N, 15 deg 37' 7.84" E The "Metadata" Tab is also showing the same Information (1.jpg). But unfortunately the map shows the image at Longitude and Latitude 0 (2.jpg). As a result all images in my library are shown in the Atlantic ocean. The Geolocation-Editor shows the correct location (3.jpg), but saving it doesn't change the position on the regular map. If I filter my Library by "Images with Coordinates" no Images are found. Thanks for helping
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.