Updating GeoTags from a GPX file fails

[lintujuh]

trafficstars

Describe the bug Updating GeoTags from a GPX file fails in a write error

To Reproduce Steps to reproduce the behavior:

1. Open a folder with images
2. Import a matching GPX file
3. GeoTags are not updated
4. See error

Expected behavior GeoTags are assigned.

Screenshots The output of the assignment process

Loaded 886 points from XML-format GPS track log file 'C:\Users\user\Downloads\2024-03-31.gpx'
  GPS track start: 2024:03:31 08:07:38.000 UTC
  GPS track end:   2024:03:31 10:33:13.000 UTC
Writing File:Geotag
Source file C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles\_3310188.ORF.xmp does not exist
======== C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles\_3310188.ORF.xmp
Setting new values from //192.168.3.1/Multimedia/Pictures/2024/03/2024_03_31/_3310188.ORF
  Geotime value:   2024:03:31 07:28:13.000 UTC
Source file C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles\_3310189.ORF.xmp does not exist
======== C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles\_3310189.ORF.xmp
Setting new values from //192.168.3.1/Multimedia/Pictures/2024/03/2024_03_31/_3310189.ORF
  Geotime value:   2024:03:31 07:28:33.000 UTC
Source file C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles\_3310190.ORF.xmp does not exist
======== C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles\_3310190.ORF.xmp
Setting new values from //192.168.3.1/Multimedia/Pictures/2024/03/2024_03_31/_3310190.ORF
  Geotime value:   2024:03:31 07:28:39.000 UTC
    0 image files updated
    3 files weren't updated due to errors

I have rebooted my PC, if there was any glitches.

Desktop (please complete the following information):

• OS: Windows 11 Enterprise 23H2
• Language/Culture en-FI
• Full Path of Picture: see the log

Additional context In my settings, I have allowed updating directly the .ORF files.

[nemethviktor]

Hi,

I'm having trouble reproducing the issue. I still have one of your previous ORF + GPX combos so I used that but I don't really think that it's file-specific (of course if you don't mind sending the ones you use I'm happy to test).

That said -- your file is on a network drive with an IP address (Setting new values from //192.168.3.1/Multimedia/Pictures/2024/03/2024_03_31/_3310188.ORF). I'm going to have trouble testing against that but what if you moved it to a local folder?

I've tried it with a UNC path \\vmware-host\Shared Folders and still works. However I see that you are using // rather than \\ and that's unlikely to work - now the thing is that the GPX import is actually fully handled by exiftool and GTN just provides an interface of sorts. There should be a file C:\Users\VN_WM_W11\AppData\Roaming\GeoTagNinja\exifArgsToWriteForTrackExport.args (in the appropriate local folder) that should have stuff like

-geotag=\\vmware-host\Shared Folders\Gateway\gtn\pics_mod\2023-02-28.gpx -geotime<${DateTimeOriginal#} -api GeoMaxIntSecs=1800 -api GeoMaxExtSecs=1800 \\vmware-host\Shared Folders\Gateway\gtn\pics_mod\_2280104.ORF -v2 -srcfile C:\Users\VN_WM_W11\AppData\Roaming\GeoTagNinja\tmpLocFiles\%F.xmp -overwrite_original_in_place

if that executes okay in exiftool (aka cmd -> C:\Users\VN_WM_W11\AppData\Roaming\GeoTagNinja>exiftool -@ exifArgsToWriteForTrackExport.args) [mind the space after the at-sign.] then the issue is w/ GTN and I'll somehow need to figure it. If it fails then the issue is with exiftool.

Re your old file(s) with the settings below on a local drive here:

Loaded 487 points from XML-format GPS track log file 'C:\temp\2023-02-28.gpx' GPS track start: 2023:02:28 12:56:18.000 UTC GPS track end: 2023:02:28 15:16:24.000 UTC Writing File:Geotag Source file C:\Users\VN_WM_W11\AppData\Roaming\GeoTagNinja\tmpLocFiles_2280104.ORF.xmp does not exist ======== C:\Users\VN_WM_W11\AppData\Roaming\GeoTagNinja\tmpLocFiles_2280104.ORF.xmp Setting new values from C:/temp/_2280104.ORF Geotime value: 2023:02:28 13:09:03.000 UTC (local timezone is +00:00) ... etc (works ok)

[nemethviktor]

Alternatively...see if this works? https://drive.google.com/open?id=16laoPJcsJJz6mdkcjWvoQu6wWXiILbQy&usp=drive_fs

[nemethviktor]

Me again.

I had a look at this and installed the FI version of Windows. I think it's a culture issue that's specific to how the Finnish (culture setting in Win) seems to handle this vs how exiftool handles this. TLDR is that in the code change above I explicitly forced a change from / to \ and so I now have in the FI version:

And yet it's still a bit odd/not being respected by the system.

I know the s/s is a bit busy and it's W10 but that latter doesn't matter. Basically in the arg file (right hand side) the values are correct, stuff is being pulled from \\vmware-host but in the exiftool output (middle) it's //vmware-host [not in the first few lines but a bit below], which is incorrect or might trigger an error with ip-address-based stuff..

This might therefore be an issue with exiftool itself

[StarGeekSpaceNerd]

However I see that you are using // rather than \

This is from exiftool, actually, it's from Perl itself. Perl internally changes backslashes to slashes in regard to file paths.

One thing to point out is that the images were taken more than ½ hour before the start of the GPS track.

GPS track start: 2024:03:31 08:07:38.000 UTC Geotime value: 2024:03:31 07:28:13.000 UTC

That isn't the direct problem here, as the exiftool output shows it is looking for an XMP file that doesn't exist. The time mismatch should have caused exiftool to report Warning: No writable tags set.

All that said, when I test locally with a file outside of the track time range, I get the same error. It goes away when I adjust the time correctly.

[nemethviktor]

However I see that you are using // rather than \

This is from exiftool, actually, it's from Perl itself. Perl internally changes backslashes to slashes in regard to file paths.

One thing to point out is that the images were taken more than ½ hour before the start of the GPS track.

GPS track start: 2024:03:31 08:07:38.000 UTC Geotime value: 2024:03:31 07:28:13.000 UTC

That isn't the direct problem here, as the exiftool output shows it is looking for an XMP file that doesn't exist. The time mismatch should have caused exiftool to report Warning: No writable tags set.

All that said, when I test locally with a file outside of the track time range, I get the same error. It goes away when I adjust the time correctly.

Thanks for the reply as always ;) @lintujuh can you check please if you adjust the time shift if it'd work?

[lintujuh]

Hi!

Thank you both. I had forgotten to change my camera to DST, so there was one hour difference between the timestamps in camera and in the GPS log. When I corrected the timestamps in the image, it worked perfectly.

It would be good to point to the user the real issue, now the error message creates too many questions.

[nemethviktor]

That would need to be changed in exiftool I think. @StarGeekSpaceNerd is that something you can help with please or I should mention it on the ET forum?

[StarGeekSpaceNerd]

I don't know enough about the inner workings of your program to know what's going on. The file name tmpLocFiles_2280104.ORF.xmp indicates that there's supposed to be a temporary XMP file? Is there a reason it isn't being created?

As I said, the error should be Warning: No writable tags set, as this would be Geotag Troubleshooting #2.

[nemethviktor]

C:\Users\user\AppData\Roaming\GeoTagNinja\tmpLocFiles_3310188.ORF.xmp does not exist

That is correct as is because at the time of the script running it doesn't exist. I think some of the message outputs from exiftool are a little confusing.

If you look at the last screenshot of mine (with the Finnish stuff, Windows 10 etc.) the ET args file is on the right hand side, that's basically what gets executed. GTN doesn't do anything apart from that, just puts the output from ET onto the screen.

Edit: the warnings just come from ET directly.

Edit 2: I don't have the current file from Juha (which would be the one that failed) but the point is that whatever shows in GTN is just whatever ET relays.

[StarGeekSpaceNerd]

Do you have an example exifArgsToWriteForTrackExport.args file? I assume that is created on the fly? I think I'm getting the idea. It may still require Phil's help, but it would be best to clarify what exactly is happening.

[nemethviktor]

-geotag=D:\temp\gpx\2023-02-28.gpx
-geotime<${DateTimeOriginal#}
-api
GeoMaxIntSecs=1800
-api
GeoMaxExtSecs=1800
D:\temp\gpx\_2280104.ORF
-v2
-srcfile
C:\Users\nemet\AppData\Roaming\GeoTagNinja\tmpLocFiles\%F.xmp
-overwrite_original_in_place

probably obvious, but in case not, the gpx file...is the gpx file and the .orf file in this case is the image but it can be any other img file.

[StarGeekSpaceNerd]

Ok, that's what I thought might be happening. The does not exist can be ignored because you're using the -srcfile option. I've been testing with just one file, so the output has been more specific, but it looks like I need to set up several files. Off to test some more.

[nemethviktor]

If that helps anything the multiple combinations are similar in the args file

[StarGeekSpaceNerd]

It looks like the useful error messages here are sent to stderr, while the output listed is stdout.

I redirect the normal output into a file and more useful error messages are displayed on the command line.

C:\> exiftool -P -overwrite_original -geotag Y:\Data\dump\Text\Geotracks\2013-03-23_104201.gpx Y:\!temp\x\z  -srcfile %d%F.xmp  -v2 >temp.txt
Warning: Time is too far before track in File:Geotime (ValueConvInv) - Y:/!temp/x/z/001.jpg
Warning: No writable tags set from Y:/!temp/x/z/001.jpg
Error: Nothing to write - Y:/!temp/x/z/001.jpg.xmp
Warning: Time is too far before track in File:Geotime (ValueConvInv) - Y:/!temp/x/z/002.jpg
Warning: No writable tags set from Y:/!temp/x/z/002.jpg
Error: Nothing to write - Y:/!temp/x/z/002.jpg.xmp
Warning: Time is too far before track in File:Geotime (ValueConvInv) - Y:/!temp/x/z/003.jpg
Warning: No writable tags set from Y:/!temp/x/z/003.jpg
Error: Nothing to write - Y:/!temp/x/z/003.jpg.xmp
Warning: Time is too far before track in File:Geotime (ValueConvInv) - Y:/!temp/x/z/004.jpg
Warning: No writable tags set from Y:/!temp/x/z/004.jpg
Error: Nothing to write - Y:/!temp/x/z/004.jpg.xmp

Maybe capture or redirect stderr as well?

[nemethviktor]

Gotcha. Ok I've patched (not made a public build) so assuming a 0-second boundary (just to trigger the error, so changed all the 1800 values to 0) we go from

to

[lintujuh]

No writable tags set/Nothing to write are still very obscure. It would be good to get also the reason why the coordinates were not written, i.e. the message Warning: Time is too far before track in File X.X

[nemethviktor]

With the current (new) code if exiftool's message include the reason it'd be passed on to gtn. If you'd like even more detailed messages that'd need to be a feature request for Phil or other ET Devs... If you don't mind sharing the gpx file and photo(s), do so please (you have my email I think if you prefer that but regardless [email protected]) and I can test or I can make a build tomorrow morning and you can play around w it.

[nemethviktor]

Ok so I now have the original set of files but when I execute in ET I still only get:

...which has no reference to the time gap being too large. How come you have that in the output? @StarGeekSpaceNerd

[StarGeekSpaceNerd]

That is a good question. I tested again with both 12.84 and 12.50, and I still have that output. I thought maybe I have something in my config file that did it, but when I tried using a nonexistent config file (exiftool -config a) which disables my normal config, I still get it.

Here's the test files and track I used. Maybe try it on the command line with "-geotime<SubSecDateTimeOriginal" so the embedded time stamps are used? z.zip

[nemethviktor]

Sooo if I comment out -geotime<${DateTimeOriginal#} then it seems to add the error line

But when it's left in (as it's currently in the code)

The relevant line doesn't show. Edit - when using SubSecDateTimeOriginal it's the same as what I have now, ie the line only shows when there's no -geotime code line

[StarGeekSpaceNerd]

What happens when you try the command directly on the command line, without using the args file?

Otherwise, I'd say it's time for Phil's input on this.

[nemethviktor]

That seems to work I think exiftool -geotag=D:\temp\2013-03-23_104201.gpx "-Geotime<DateTimeOriginal#" -api GeoMaxIntSecs=1800 -api GeoMaxExtSecs=1800 D:\temp\001.jpg -v2 -srcfile %F.xmp -overwrite_original_in_place

[nemethviktor]

Kindof a p.s. note but if I change the args file from -geotime<${DateTimeOriginal#} to -Geotime<DateTimeOriginal# it works

my original code was from here https://exiftool.org/forum/index.php?topic=14598.msg78652#msg78652

[StarGeekSpaceNerd]

Yeah, the dollar sign is needed when you add a time zone, as that is a mixed tag and static string. It has something to do with removing context, something I don't fully understand. But the relevant documentation is the exception under Common Mistake #5.

[nemethviktor]

Sooo ask Phil? (you or me? :))

[StarGeekSpaceNerd]

You should. I have a busy week and you would have to respond if he has more questions.

[nemethviktor]

Ok thanks, will do

[nemethviktor]

Ok @lintujuh can you play around with this one please https://drive.google.com/open?id=16laoPJcsJJz6mdkcjWvoQu6wWXiILbQy&usp=drive_fs

(apparently -v2 in an arg file returns less "extra" info than in cmd so we need to set it to -v3, which in turns does a fair bit more but alas.

[lintujuh]

Tested with images that were past the end of the GPX track, and gtn showed the error message. You had to look closely the error messages to pick it up, but I think that is nothing you can do to it.