Bug: 0.10.2 Time sync error when using separate GPS info

[DonkeyShine]

I'm trying to generate an output using a video file (from a Instal360 Go 3S) and a separate .FIT file. It's failing using the GPStitch GUI with the following error:

However, if I cut-and-paste the output of the Get Command button and run it within a terminal (using the version of gopro-dashboard.py located within the gpstich venv), it works successfully, showing these time ranges:

GPX/FIT file: 2026-02-06T18:10:23+00:00 -> 2026-02-06T20:02:53+00:00
Video File Dates: 2026-02-06T19:34:47+00:00 -> 2026-02-06T19:35:37+00:00

As you can see, the Video File Dates differ by what appears to be my local timezone (PST8PDT).

I'm not certain, but I think this may also be the cause of the

error when attempting to generate a preview.

A stat of the video file shows these dates:

Access: 2026-03-13 09:02:58.670778598 -0700
Modify: 2026-02-06 11:34:47.000000000 -0800
Change: 2026-03-13 08:49:37.351333467 -0700
Birth: 2026-03-12 20:20:56.498970336 -0700

Since the command given to gopro-dashboard.py includes --video-time-start file-modified, I think it's the Modify time that's critical here.

I tried using touch to set the Modify time to something completely different (18:00:00), but when loading it into the GPStitch GUI, the timestamp was the same as the first screenshot. Huh?

Is it possible that you're getting the video times via some mechanism other than the file's mtime inside of GPStitch?

Thanks again for your efforts and please let me know if there's anything else you need to help diagnose this issue.

[Romancha]

Fixed in v0.13.0.

The root cause was that cameras like Insta360 write local time into the MP4 creation_time metadata tag, but ffprobe always reports it as UTC. This caused a timezone offset mismatch, leading to the "No GPS data found for video time range" error in both preview and render.

GPStitch now cross-validates creation_time against the GPS data range. If creation_time doesn't overlap the GPS track but the file's mtime does, it falls back to mtime - which correctly reflects the local timezone.

This also explains why Get Command + manual CLI worked: gopro-dashboard.py with --video-time-start file-modified uses mtime directly, bypassing the creation_time issue.

[DonkeyShine]

Thanks for working on this. Alas, it doesn't seem to be quite right yet. I tried a test this morning with my Insta360 Go 3S.

ffprobe run on my file shows this time:

    creation_time   : 2026-03-31T10:32:32.000000Z
  Duration: 00:00:54.09, start: 0.000000, bitrate: 31075 kb/s

which, as you noted, is incorrect. The creation time is in local time, but has a Z indicating UTC. The actual creation (wall clock) time was 2026-03-31T17:32:32.00Z.

The first time in my .fit file is 2026-03-31T17:26:00Z and the last is 2026-03-31T17:46:58Z, so the video file is completely within the GPS data.

But GPStitch is showing a No GPS data found error:

I'm not sure if it's relevant at all, but using the stat command on the video file shows a Modify date which is about 7 hours too early:

stat VID_20260331_103242_00_004.mp4
  File: VID_20260331_103242_00_004.mp4
  Size: 210095744 	Blocks: 410344     IO Block: 4096   regular file
Device: 0,41	Inode: 63689512    Links: 1
Access: (0755/-rwxr-xr-x)  Uid: ( 2000/    user)   Gid: ( 2000/   group)
Access: 2026-03-31 20:06:26.405895725 -0700
Modify: 2026-03-31 03:33:36.010000000 -0700
Change: 2026-03-31 12:29:15.343042766 -0700
 Birth: 2026-03-31 12:29:09.364040317 -0700

If I reset the Modify time on the video file (using touch -d "2026-03-31T10:32:32.000000" VID_20260331_103242_00_004.mp4) GPStitch works fine.

Please let me know if there's anything else I can provide to assist in troubleshooting.

Thanks again!

[Romancha]

Fixed in v0.14.0.

v0.14.0 adds automatic timezone correction: when neither creation_time nor mtime overlaps the GPS track, GPStitch now compares creation_time to the GPS data midpoint, calculates the offset, and rounds it to the nearest 15-minute timezone boundary. The correction is applied automatically, and a warning is shown in the UI indicating the detected offset.

This should handle your Insta360 case without needing to manually fix the file's mtime with touch. Please give it a try and let me know if it works for you.

[DonkeyShine]

Thanks for working on this - it sounds like an interesting approach to the problem. Unfortunately, it's still not working. I just pulled v0.14.0 and tried it on a Go 3S file that I created this morning. The first entry in the GPS log is: 2026-04-09T16:37:20Z and the last is 2026-04-09T17:58:15Z. I'm in timezone PST8PDT so local time is 7 hours previous since we're in Daylight Savings Time (DST) right now.

Per ffprobe, the video's start time and duration are:

    creation_time   : 2026-04-09T09:45:39.000000Z
  Duration: 00:01:48.34, start: 0.000000, bitrate: 40303 kb/s

So the times align (with the Insta360 correction), but the GPStitch GUI still shows no overlap:

Just for grins, I switched to manual and put in a -7 hour offset, and that worked to generate a preview, but either the Video start or end times are now wrong, depending on how you want to present those numbers (see bottom of screenshot below):

The actual rendered video is correct, however. Is it possible that Daylight Savings Time (DST) is causing an issue?
Let me know if there's anything I can provide to assist with getting a functional workaround.

[Romancha]

Thanks for the super-detailed report!

The v0.14.0 midpoint approach had a fundamental flaw: it expected video and GPS durations to be roughly similar, so it refused to correct your case (108s video inside a ~80 min track). That's actually the common workflow for external GPS + non-GoPro cameras, not the edge case I designed for.

Coming in v0.14.1 — the Auto time sync is rewritten as an explicit cascade:

1. creation_time as-is overlaps GPS → no correction (GoPro and similar)
2. creation_time shifted by the system timezone overlaps GPS → apply that
3. Exhaustive whole-hour overlap search → pick the unique match
4. mtime as-is (last resort)
5. None of the above → error banner with a one-click "Switch to Manual with +Xh" button, pre-filled with the best-guess offset

For your exact numbers:

• creation_time = 2026-04-09T09:45:39Z
• system TZ = PDT (UTC-7)
• shifted = 09:45:39 + 7h = 16:45:39Z → inside GPS 16:37:20-17:58:15Z ✓
• Auto mode applies +7h via the system-tz path, no user intervention.

On the DST question — yes, DST is handled. The offset comes from Python's datetime.now().astimezone().utcoffset(), which returns the current local offset including DST, not a fixed zone.

On the confusing Manual panel display you flagged — Video: X → Y was indeed ambiguous. It now shows three clearly labeled rows:

Original creation_time:  Apr 9, 09:45:39
Corrected video start:   Apr 9, 16:45:39
GPS range:               Apr 9, 16:37:20 — 17:58:15

Edge case worth mentioning: if you record while traveling and your system TZ doesn't match the recording TZ, the cascade falls through to exhaustive search; if that's still ambiguous (multiple whole-hour offsets fit), you'll get the error banner with the Switch-to-Manual button pre-filled with the best guess — so you're one click away instead of typing seconds by hand.

Thanks again for the patience and the thorough repros :)

[DonkeyShine]

Thank you for the detailed write-up - it's much appreciated. It sounds like your logic will catch the vast majority of cases, though I can think of a few that it might miss, for example:

• On road-trip vacations, I've often starting GPS logging at the first stop of the day and not stopped it until the end of the day (sometimes 10+ hours of logging). So a short video recorded near the beginning of the day might match the GPS dates both with and without the timezone offset.

• A short video and short GPS track recorded before a DST change, but GPStich-ed after the time change might still fail, but as you say should fall through to the manual override option.

But as long as the manual override option exists, it should be possible to handle all cases.

I almost think it might be easier to just have a ✅ Video times are UTC checkbox with the default being checked, though that might require a bit more knowledge on the part of the user.