SUMMARY I have been reverse geolocation several groups of peoples for a couple of days, and I noticed that in some cases (not sure if all of them), the original tags (including face tags) are replaced by the tags created by the reverse geolocation tool. STEPS TO REPRODUCE 1. Select one picture with tags and GPS coordinates (or add them manually) 2. Go to Tools/Edit Geolocation. 3. On the Reverse Geocoding tab, select the picture, and click "Apply reverse geocoding". 4. Wait until it finishes, and click "Apply". OBSERVED RESULT The picture will only have the tags assigned by reverse geocoding, losing all other tags (including people in the picture) EXPECTED RESULT The tags obtained by reverse geocoding should be added to the existing tags of the picture, not replace them. SOFTWARE/OS VERSIONS Linux/KDE Plasma: digikam-6.4.0-git-20191005T120037-x86-64.appimage in Ubuntu 18.04 LTS. (I know it's neither a stable release nor the last unstable built, but I think it was the last available build of the 6.4 branch)
Sorry, I meant "I have been reverse geolocation several groups of pictures (...)"
Hmm, I have only digiKam-6.0.0 on openSUSE Leap here right now. I can not reproduce it. Even after a quick look at the source code, the old tags list will not be deleted. I test it tonight with the current version... Maik
I will try to reproduce it using some test pictures, to try to find out in which cases it happen.
I can not reproduce the problem. Can it be related to your no longer existing disk space for the databases? Maik
No, the low disk space was something temporary because some log files grew unexpectedly huge in my system. But when that happened, no tags could even be saved. I tried right now, from a fresh Digikam session, and I can reproduce it consistently. I recorded a screencap as an example. You can watch it here: https://imgur.com/a/75gpnSt In it, I selected a picture with GPS coordinates, I added a "test tag", then used the reverse geolocation tool. When I clicked apply, the tags used by the reverse geolocation tool replaced the old ones, including "test tag".
No, not to reproduce here, test tag remains. Do you use sidecars? If so, read and write mode? Maik
No, I have sidecars disabled completely (both read and write). Maybe it's that particular build. Do you want me to test a specific version?
The output of the console may be interesting from assigning the test tag to reverse geolocation. Gilles, can you reproduce a problem here? Maik
Hi Maik, No. I just tested with AppImage 6.4.0, and i cannot reproduce the problem. Perhaps the database is corrupted ? The console trace will help to investiguate. Gilles
Created attachment 123777 [details] 1. Writing "test tag" to picture.
Created attachment 123778 [details] 2. Opening reverse geolocation tool
Created attachment 123779 [details] 3. Applying reverse geolocation
Created attachment 123780 [details] 4. Clicking "Apply", saving the new tags to file At this point, is when the "test tag" is deleted from the metadata and replaced with the tags from the reverse geolocation tool.
Created attachment 123781 [details] 4. Clicking "Apply", saving the new tags to file
Ok, so I captured the output of this action in debug mode. I decided to separate the logs in four parts, so it's clear what digikam is doing in each one of them. 1) I write a test tag called "test tag" to the picture IMG_20191014_165515.jpg. This picture already had other tags: "Espanya", "Espanya/Andalusia", "Espanya/Andalusia/Almeria", and "Espanya/Andalusia/Almeria/Tabernas". I can confirm that the new tag has been saved by using an external tool to explore the metadata. 2) I open the Edit Geolocation tool, already showing the reverse geolocation tab. By the way, on the list of tags in that tool, the picture is not showing any of them. 3) I select the picture on the list, and I click on "Apply reverse geolocation". The tags in this window are populated again. 4) I click the Apply button to save the metadata to the file. At this point, the old tags are replaced by the new ones provided by the reverse geolocation. (PS: I had to upload this logfile twice, make sure you see the last version) By the way, capturing the output was not easy due to the huge amount of text outputed. Specially these two lines, which were repeated literally thousands of times: unknown: Numeric mode unsupported in the posix collation implementation unknown: Ignoring punctuation unsupported in the posix collation implementation
You have activated the metadata option "Cleanup database when file re-scanned"!!! This option is only to be activated in the case of problems, if "old" metadata that is no longer required should be removed from the database. This option must never be permanently activated! I will change the text again and disable this option automatically with every start. Maik
Ok, I see, that option was the source of the problem. But I don't see why it should work this way. In theory, when entering the reverse geocoding tool, it should read the current picture metadata, and not just overwrite it with new tags. I still think it is a bug. In any case, that option is very useful when using a shared picture library. I would say it is a must (other picture managers also work this way by default). If another user changes metadata in a picture (or myself in another computer), I want those changes to be reflected in my database the next scan. Otherwise, my database can be populated with metadata that the pictures don't actually have. I want my library to be a 1:1 reflection of the contents of all the pictures.
Well, the problem actually seems to be even deeper, because with me there are no problems even with active "Cleanup Database" option. I can see that the test tag already does not exist in the geolocation editor. Have you changed the advanced metadata settings and do not write or read the digikam tags list anymore? Maik
No, I don't think I have ever changed anything from the advanced metadata settings (I can send you a screenshot if you want). I also have all sidecars disabled, and in the behavior tab, I only have selected the three last options (Update, Rescan and Cleanup). I just tried on the stable 6.4.0 release that I just downloaded, and I also tried it in the 7.0.0 beta build (digikam-7.0.0-git-20191102T132323-x86-64.appimage), with the exact same result. I also checked the four database files using the sqlite3 tool, and performing a PRAGMA integrity_check in each one of them, with no problems found. I also used a new database in a different folder, and the problem was still there. Then I decided to rename the ~/.config/digikamrc configuration file... and there it is! Now the reverse geolocation tool does not remove the old tags anymore!! So it has something to do with the configuration file.
Created attachment 123784 [details] Offending digikamrc configuration file I have attached the offending digikamrc configuration file, in case you want to have a look. There must be some option somewhere that causes the problem.
Git commit 3acf2889023b5203a71fe72433d037e6004f26b4 by Maik Qualmann. Committed on 07/11/2019 at 20:54. Pushed by mqualmann into branch 'master'. fix tag list from reverse geolocation if write to XMP enabled FIXED-IN: 7.0.0 M +2 -1 NEWS M +6 -3 core/utilities/geolocation/geoiface/items/gpsitemcontainer.cpp https://invent.kde.org/kde/digikam/commit/3acf2889023b5203a71fe72433d037e6004f26b4
Thanks for the digikamrc, so I could reproduce the problem. The geolocation editor has a database interface in digiKam mode, enabling the option writing the metadata in XMP is not necessary. This option is actually only needed in showFoto. In fact, the old tag list was not loaded and used here. Maik
One more note: you have enabled the database cleanup on the start, this I do not think necessary. Maik
I started fresh with a new digikamrc config file, and enabling those options ("Cleanup database when file re-scanned"), the issue is still there. However, it does not remove face tags, just regular tags ("test tag" was removed, but not tags with the name of people in it). So it basically seems to be that option that triggers that behavior. In any case, I think I need to leave it enabled (and I personally think it is quite important). Otherwise metadata is never removed from the database, even if you re-scan the item manually. For instance, I just tried it right now. I added some tags to a picture. Then I closed digikam, and using an external editor, I removed all the metadata. I started digikam again, and the metadata was still there, even if I "Reread metadata from file". Then I enabled it, and re-reading the metadata finally updated the picture, removing the non-existing tags. The option to "remove obsolete core database objects" might delete non-existing pictures, but does not remove deleted metadata from existing ones.