Bug: New GPS data is ignored in JPG files, if the file already has an XMP sidecar

There is definitely a bug in Mylio.
If a JPG file has XMP sidecar files, a new GPS coordinate in the JPG is ignored, although other data is updated.
If a JPG file has no sidecar yet, a new GPS coordinate is imported from the file by Mylio.

See also following thread:

This may be by design. I observe that if I export a new image to Mylio from a different raw editor (as a single JPEG, without using _display versions), Mylio reads the metadata but does not create an XMP sidecar. If I then decide I don’t like the way the image looks, I go back to the original editor and export a new version, overwriting the previous one, and Mylio reads any new metadata in the absence of the sidecar. However, if I update the metadata in Mylio (any of it - title, caption, geotag etc), an XMP sidecar is created; if I then decide I don’t like the way the image looks, I go back to the original editor and export a new version, overwriting the previous one, but the now-edited metadata in the XMP sidecar is retained by Mylio, avoiding me having to re-do the changes. I think this is a good thing. In the GPS scenario linked, I think IMatch needs to update the sidecar’s geotag, if the sidecar exists. This is, of course, an artefact of Mylio’s use of sidecars even for JPEGs.

I really hope it is not the case, because that would be a first step to abandon Mylio.
It is also a fact, that the GPS data was not updated, but the Title was, even when an XMP sidecar was there for a JPG file, but the Title was empty.
I might make another try with overwriting other fields and see, how Mylio behaves there.

Then at least it would need an option what data to prefer: the one with the latest timestamp or the one in the database.

Should this be really by design, I would let Mylio save the metadata to all my phone files right away, but this would cause a myriad of duplicates, as Mylio is not able to tell, if a file is already imported (by Mylio) from the phone, if one saves metadata to the same file.

So it actually looks more like a “by design” behaviour.
After a JPG file has an XMP sidecard, it is handled as the “source of truth” and changes from other apps made to the file directly are ignored to the fields, that were previously populated in Mylio.
Values are taken over, as long as the field was previously empty in Mylio.
Values are also taken over, when the field was not edited in Mylio before.

And I don’t really like it this way.
This only creates a mess with two possible values and not understanding, why a change made elsewhere is not visible.

A setting to prevent creation of separate XMP files for non-raw images would sort this out, I think!
There is always a slight risk of data corruption when updating a JPEG with metadata changes, of course.

This would lead to sync performance issues, as discussed previously on this forum (Add an option to always “Save Metadata to File” - Feature Requests - Mylio Community). The entire image file would need to be re-synced whenever even a single bit of metadata is changed. As I recall, Mylio folks were looking into partial-file or block-level replication to mitigate this. Haven’t heard lately if this is still on their roadmap.

Another workaround would be a way to explicitly re-load the enbedded metadata from the image file. User would need to confirm over-write in case of conflict with XMP sidecar.

Replace “Scan for Changes” with “Read Metadata from File” - Feature Requests - Mylio Community

1 Like