Glithes started to appear recently in my sequences.
I didnt changed anything in my workflow:
Using gopro 8 black in photo timelapse with 1-5 sec interval.
Uploading with mapillary tools (0.7.0 and 0.8.0 same behaviour)
Example sequences:
Viewed first sequence, when disregarding green line connecting pics see that photos which are next to each other on the map show what one would expect to see on the next frame; what is incorrect is the green line which connects photos that were taken like a minute or so later .
That problem was reported by another user some months ago, and I have experienced the same issue.
Viewing the original pics which were on my computer spot that there is a glitch in the file time-stamp.
Have found a work-around which at least does away with those green ‘spike-lines’ connecting unconnected pics : added command --cutoff_distance 30 which at least avoids those spurious lines, but has the effect of chopping (in my case) a 7200 pic sequence into 186 sequences of alternatingly 59 pics , then one pic, then again 59 , but at least it does away with the spikes all over the map.
Chosen cut-off 30 as my cycling is at a speed of 5 or 7 m/s, thus won’t cut unnecessarily.
Now, before posting : did I put this a clearly as possible?
Perhaps two links say more than all those words :
Used to see spikes like this : Mapillary where the pics /are/ in the right spot, but once in a while every sixtieth is erroneously connected to pics taken 59 and 61 seconds earlier.
after instruction to set cutoff-distance don’t see those pesky spikes anymore, but there are loose dots = pics : at the correct spot in the sequence, but no longer connected via the green line. See for example Mapillary , and note that that single dot points north as there are no other dots in its ‘one-dot-sequence’ to normalise with.
Note image G0014855 , file system created time 14:58:00 , previous image G0014854 file system created time 14:58:59 , subsequent image G0014856 file system created time 14:59:01 : thus the middle image ought to have been filed at 14:59:00, but for some reason was saved after incrementing the seconds, but before incrementing the minutes
And in case you wondered : the pics are spaced at equal intervals, but two adjacent ones (ending in …54 and …55) share the same GPS DateTime exif-value : thus my previous (and now removed from this post) suggestion to change file system time taken to GPS time taken will not resolve the issue.
Note that due to the clock which sets time talen for the file system running fast (by approx 6secs/24hrs) there is a small difference between File time and GPS time; looking back in the sequence notice that pic ending …50 has GPS time 13:57:59Z , pic ending …51 has GPS time ending 13:58:01Z - there is apparently no pic with GPS time taken 13:58:00Z : there obviously is something the matter in the Hero (mine’s a 9, the OP’s an 8) at the change of the minute, but little the user can do.
It would be nice if this could be resolved, but at a loss /how/
Met vriendelijke groet (Dutch for ‘with friendly greeting’,
@tao : give that you’re involved in the Command line Mapillary Tools : may I include your user name in the hope that making you and the github team aware can lead to a solution?
(One method comes to mind while typing : when there’s a potential spike in the green line - defined as an apparent sudden speed increase between pics - : check picture file name (number, in the case of GoPro) , and if that pic’s location is nearer pics with one lower and one higher number (thus location) : draw the green line in sequential order of picture file name.
Suggested instruction to invoke this : --for_green_line_use_file_number ) - which I’d use for every upload, as there are spikes in every sequence and I retain the GoPro assigned file number as name.
Great analysis of the problem! 
Before I was using Gopro 7 black without this effect.
I looked closely on data included in the problematic photo (one with bad minute) and there are fields with correct
time. It would be enough to copy it to the field mapillary is using or make mapillary tools take it (it could be automatic trigered by the camera identification tag)
Interestingly the effect only shows up from time to time. Maybe its due to different SD cards used? Its rather not to the timelapse interval because I have same errors on 1sec and 5sec intervals. Again I find Gopro cameras highly unreliable.
Unfortunately I dont have EXIF editor with batch edit option to transfer data between those time fields.
I will try to alter my workflow now to go around it. The easiest way would be to overwrite timestamp to actual one when cropping photos (removing car hood). We would get bad timestamp in mapillary but good picture order 
Ok, I pinpointed the problem in GoPro.
There are two fields:
Date Created & Date Modified.
Go pro is writing minutes value from Date Modified in Date Created minutes. So when that two fields are close together (like when you synchronize the time with cell) no problem, but when you i.e. change the battery or loose power, that two timestamps drift apart, and everything gets messy. Hard to explain this. Better to analyse your files (with Bridge or other img viewer like FastStone)
The simplest way would be to make mapillary tools use Date Modified or GPS timestamp tag.
And workaround for now would be to process all gopro photos with exiftool. So my question:
Is here some specialist dealing with Exiftool to help write command line for copying GPS timestamp tag to Date Created tag??