The end user experience of this bug, is that:
When updating  a video file's GPS coordinate, from 0 deg 0' 0.00" N, 0 deg 0' 0.00" E to something else, the change will not be reflected on the maps of Digikam - the thumbnail of the video will remian at 0 deg 0' 0.00" N, 0 deg 0' 0.00" E on the map.

According to Claude, the problem is:

 "In dmetadata_fileio.cpp, for video files the load order was ExifTool → sidecar merge → FFmpeg. The FFmpeg loader reads the GPS location entry from the video container (+00.000+000.000/) and calls setGPSInfo(), which overwrites the sidecar GPS that was already merged.

  The fix: Move loadFromSidecarAndMerge() to run after all backends (ExifTool + FFmpeg), so user edits in the XMP sidecar always take priority over metadata embedded in the video container."


Below is a patch suggestion that passes the test in draft pr: https://invent.kde.org/graphics/digikam/-/merge_requests/397

I post is as a help for troubleshooting, hoping to fascilitate troubleshooting for maintainers.

%> git diff
diff --git a/bootstrap.linux b/bootstrap.linux
index 25fb1d6e7a..3c46e4727c 100755
--- a/bootstrap.linux
+++ b/bootstrap.linux
@@ -15,7 +15,7 @@ trap 'echo "FAILED COMMAND: $PREVIOUS_COMMAND"' ERR
 #export CXX=/usr/bin/clang++
 
 SOURCEDIR=$PWD
-export BUILD_WITH_QT6=0
+export BUILD_WITH_QT6=1
 
 if [[ $BUILD_WITH_QT6 == 1 ]] ; then
     QTPATHS="qtpaths6"
diff --git a/core/libs/metadataengine/dmetadata/dmetadata_fileio.cpp b/core/libs/metadataengine/dmetadata/dmetadata_fileio.cpp
index 3c2a97b50c..8363ae76e9 100644
--- a/core/libs/metadataengine/dmetadata/dmetadata_fileio.cpp
+++ b/core/libs/metadataengine/dmetadata/dmetadata_fileio.cpp
@@ -120,11 +120,6 @@ bool DMetadata::load(const QString& filePath, bool videoAll, Backend* backend)
 
         if ((hasLoaded = loadUsingExifTool(filePath, videoAll)))
         {
-            // Load and merge metadata from sidecar first
-            // before adding virtual metadata to XMP.
-
-            sidecarLoaded = loadFromSidecarAndMerge(filePath);
-
             if (videoAll && (hasLoaded = loadUsingFFmpeg(filePath)))
             {
                 usedBackend = VideoMergeBackend;
@@ -136,8 +131,6 @@ bool DMetadata::load(const QString& filePath, bool videoAll, Backend* backend)
         }
         else
         {
-            sidecarLoaded = loadFromSidecarAndMerge(filePath);
-
             if (videoAll && (hasLoaded = loadUsingFFmpeg(filePath)))
             {
                 usedBackend = FFMpegBackend;
@@ -147,6 +140,11 @@ bool DMetadata::load(const QString& filePath, bool videoAll, Backend* backend)
                 usedBackend = NoBackend;
             }
         }
+
+        // Merge sidecar after all backends so user edits take priority
+        // over metadata embedded in the video container.
+
+        sidecarLoaded = loadFromSidecarAndMerge(filePath);
     }
 
     qCDebug(DIGIKAM_METAENGINE_LOG) << "Loading metadata with"

The issue has already been fixed in git/master, though the update hasn't yet appeared here. I'll wait a little longer; sometimes the bug tracker is slow.

Loading sidecar files cannot be performed after all backends; otherwise, we wouldn't be able to filter out the "virtual" video metadata during the write process. The whole system has become somewhat complex by now.

Maik

Git commit 3450cc957f3a75b4b94491f515941c81bd54abd1 by Maik Qualmann.
Committed on 18/05/2026 at 18:12.
Pushed by mqualmann into branch 'master'.

disable reading of GPS data from the FFmpeg video metadata backend
As with the date, this is already handled by ExifTool for video files.
FIXED-IN:9.1.0

M  +1    -1    NEWS
M  +2    -2    core/libs/metadataengine/dmetadata/dmetadata_video.cpp

https://invent.kde.org/graphics/digikam/-/commit/3450cc957f3a75b4b94491f515941c81bd54abd1

Looks good in digiKam-9.1.0-20260519T100128-Qt6-x86-64.appimage
Thanks for the fix :-)

After updating to 9.1.0, when reading metadata from a video file, it won't update the database using the QuickTime:GPSCoordinates tag. I think this is a side effect of this bug correction.

I cannot reproduce the issue. I suspect that, possibly due to previous bugs, there are no GPS coordinates in the sidecar file. In that case, the image's GPS coordinates are used instead.
In any case, XMP GPS tags in digiKam always take precedence over Exif/QuickTime tags.

Maik

Created attachment 193481 [details]
MP4 file with QuickTime:GPSCoordinates

I attached a small video file containing only GPS information in the QuickTime:GPSCoordinates tag. When reading metadata from this file in 9.1.0, no GPS information is found and written to the database. This works using 9.0.0.

Git commit a7b2972c2c39552a1f174b780a42369286b1bd52 by Maik Qualmann.
Committed on 21/06/2026 at 11:14.
Pushed by mqualmann into branch 'master'.

restore important GPS tags when reading with ExifTool

M  +7    -0    core/libs/metadataengine/exiftool/exiftoolparser_command.cpp

https://invent.kde.org/graphics/digikam/-/commit/a7b2972c2c39552a1f174b780a42369286b1bd52

Git commit 06003cb2b5c4de1f2e7bbb256a443a54a489e274 by Maik Qualmann.
Committed on 21/06/2026 at 11:25.
Pushed by mqualmann into branch 'master'.

use the placeholder from ExifTool

M  +2    -4    core/libs/metadataengine/exiftool/exiftoolparser_command.cpp

https://invent.kde.org/graphics/digikam/-/commit/06003cb2b5c4de1f2e7bbb256a443a54a489e274