SUMMARY digiKam-7.0.0-beta3-20200403T064555-MacOS-x86-64.pkg (and some before) does not save a new set geo location. After closing the editor the location stays unchanged. Last version it was still working: digiKam-7.0.0-beta3-20200302T092039-MacOS-x86-64.pkg SOFTWARE/OS VERSIONS Windows: - macOS: Catalina 10.15.4 Linux/KDE Plasma: - (available in About System) KDE Plasma Version: - KDE Frameworks Version: 5.65.0 Qt Version: 5.14.0 ADDITIONAL INFORMATION File is changed but the old location is written.
A new option is now available in the metadata settings to enable the writing of geolocation information. Maik
Like all other metadata write operations, the default setting is deactivated. Another innovation is that when the metadata DB -> Image is synchronized, the geolocation information is also written and updated if the option is active. Maik
Maybe it is not written to the metadata, but the new location is completely lost. If you close the geo editor the image in right map view is at it's old location. I will try the new setting option. Have to reinstall the latest version ... will send an update after that.
I have just tested it again, it works as expected, even without an active write option, the new position is taken because the geolocation data is always written to the database. The metadata will of course remain unchanged in the image. If you read the metadata again, you will have the old coordinates again. Maik
I reinstalled the latest version and I see the new option setting for geolocation information (GPS). If I set this option, new position is updated (to database and image). If I do not set this option it is again not written to image AND not to database (on Mac OSX)! It remains on the old position.
What are your metadata settings exactly? Reread the metadata on change? Clean up the database when reading again? Sidecar? Collection monitoring for external changes active? Maik
It is the option to clean up the database, this will write the content of the metadata in the image back into the database. And we have the old position. This option was not intended to be activated permanently, I tend to deactivated this option for every new digiKam session. Maik
Hmm, regardless of the database cleanup option, I can now actually reproduce a problem when updating the database. I'll take a closer look at it tomorrow. Maik
Git commit ced318151c7b7d537147805c52d19187ff8b936a by Maik Qualmann. Committed on 07/04/2020 at 04:23. Pushed by mqualmann into branch 'master'. do not reload metadata under digiKam in the Geolocation Editor FIXED-IN: 7.0.0 M +2 -1 NEWS M +5 -2 core/dplugins/generic/metadata/geolocationedit/dialog/geolocationedit.cpp https://invent.kde.org/kde/digikam/commit/ced318151c7b7d537147805c52d19187ff8b936a
Hi Maik, you are up early! :-) Just to make it complete. The following options are set (and if not noted here they are not set): All options in section "Write This Information to the Metadata". In "Reading and Writing Metadata" - Update file modification timestamp when files are modified - Rescan file when files are modified The Rescan option did not have had an impact if checked or not. I will test your change as soon as the Mac version has been compiled and uploaded. Holger
> Like all other metadata write operations, the default setting is deactivated. I personally to not like this default setting, as writing these data to the image was the default before. Without this bug I would not notice this change and live on in the belief that all my images store the correct location. Another bug is, that without the write GPS option the image file gets touched (no change, I made a diff, but file date and time are set to the current) so my cloud service uploads this file to the server. This confused me in the first time. This should be avoided imho.
Starting from a new configuration where all metadata write operations are deactivated and only activated by the user, the previous behavior was an error. We will include information about this in the release announcement for digiKam-7.0.0. I tested again whether the image is changed if the option is deactivated, no it will not. They may have written geological tags in the image, the setting for tags and geological information are separate and will be treated as such. Maik
Ok, the note will help. I will test the again with the new version as soon as it is available and report the result. Thanks for changing the code so fast!
Can someone please build the MacOS version of digikam. It wasn't updated since April 3rd. Thanks.
I do it now... Gilles Caulier
Thanks. Just tested it right now. Not setting the option to change the file now updates correctly the database. But the file date and time still gets modified. Why does this happen?
You have activated tags writing. Possible reverse geolocation tags are written/updatetd in the images and change the date. Maik
You are right. As soon as I remove the option "Image tags" the file date stays unchanged. I copied the file before this test and a diff says the old file and the file with the newer date are identical. If I allow tag write and do add a tag then diff states a difference in the files (so diff detects changes in binary files correctly). So once again, I do not understand why the file date is changed while the file is actually unchanged.
Git commit 1177a6f4972e31291f5a60dd8319d3b9e0086427 by Maik Qualmann. Committed on 11/04/2020 at 05:29. Pushed by mqualmann into branch 'master'. only write the metadata to the file if the tag list has been changed M +1 -1 core/utilities/geolocation/geoiface/items/gpsitemcontainer.cpp https://invent.kde.org/kde/digikam/commit/1177a6f4972e31291f5a60dd8319d3b9e0086427
I can confirm that geotaging now works as expected. Tested with: digiKam-7.0.0-beta3-20200413T082140-MacOS-x86-64.dmg Thanks a lot, Mike! Holger
Thanks for your feedback Gilles Caulier