Used Apple Watch to track my outdoor cycling. After imported the record to arc, a ten minutes ride became four hours ride, and the coordinates have some weird location. But if i view the outdoor cycling exercise in Apple health, everything is ok. No weird gps coordinates. Occasionally a ten minutes ride will become a super long ride, like over 24 hours.
Apple Watch series 7 + 14 pro max
All on latest os update (not beta)
This happened since long time ago. Can you guys take a look and fix it? Thx
I’m aware of this one, though I never see it with my own workout data anymore, so I haven’t had a chance to test and debug it in quite a while.
It’s likely the result of a quirk in the way the workout was recorded. I first noticed it with data imported from surfing workouts recorded by the Dawn Patrol app on my watch. For that case I gave some feedback to the Dawn Patrol dev, and he fixed something on his side, and I also fixed something on my side to make the importing more resilient to subtle weirdness. Since then I haven’t seen that one again.
So it’ll likely be something like that. And the Apple Health app is already aware of that recording/data quirk, so it knows how to sidestep it when displaying the workout to you. While Arc isn’t aware of that particular quirk yet, so it fumbles when it imports it, instead of recognising it and dealing with it appropriately.
Which app do you record the cycling workouts with? I do a lot of cycling recording myself, using mostly the Gentler Streak app, though sometimes Apple’s workouts app if it’s a longer cycle, like when touring. For both of those apps I’m not getting any import problems. So I’m guessing it’s a different app.
Though if it is either of those, then… the mystery deepens!
I just use the workout app by apple on my watch. Not 3rd party.
I basically just click workout then outdoor cycling when i begin cycling. Then click stop when I’m done cycling. Nothing special
Hmm. That does make it a mystery then… I do that every day for a lot of the year, in various different cities, and never see problems.
So I wonder if it’s not the workout that’s the problem but the surrounding data in the timeline. I was thinking maybe data gaps, so the workout item gets incorrectly presented as extending out to the full duration of the data gap. But you say over 24 hours, which … would be a very extreme data gap.
Though that’s still my most plausible guess. What do you think the chances are that it’s importing into a period where there’s a data gap in Arc’s timeline?
i only import the data through ARC by clicking import workout… nothing fancy.
sometimes the imported work out is not 24 hours, but it’s like between 4 hours to 10 hours…for a ten minutes ride.
and i checked the import that’s wrong… during that workout period, I do see a big jump of the gps coordinate to some location that’s like far away from my bike route in the imported workout. The rest of the data imported does match where i actually rode my bike. but the time is just totally wrong. the imported time range of the work out, i am at home (except during that 10 minutes ride). and my home is like only around 100 sq. meter.
So sounds like it’s just one workout that’s importing wrong, yeah? So at least it’s not a recurring problem - that’s something.
But we’re still left with the mystery of why that workout imported weirdly!
That does sound like a significant clue. I wonder if the nonsense location data is in the workout or in Arc’s own recorded data. Though for the nature of the bug I’m now imagining, it might not matter much either way. Both cases could possibly trigger the kind of bug / incorrect timeline I’m imagining…
The bug that I used to see with my surf workout imports was that typically the start of the workout had one location sample that was outside of the workout’s stated time range, and usually represented some earlier coordinate that the watch might have seen prior to the workout starting (typically some tens of minutes minutes earlier, while walking to the beach).
So the workaround I added in Arc was to ignore any location samples in the workout that fell outside of the stated time range of the workout record. If for some reason the workout got some random earlier location update prefixed to it, that would be ignored. Problem solved.
But that fix should have solved the same problem for your workout, if that’s what the problem actually is. So… yeah, I’m still stuck trying to guess what the different might be. Hmm… I’ll keep pondering.
It happens randomly and not just once. It could be totally fine for yesterday but messed up today.
For example, on the same day, my commute to the gym, arc’s record matches with apple workout after imported.
Two hours later, when i ride back to home, the workout imported totally not matching with what arc recorded.
Here is an example you can see
I imported the record to arc, Arc’s record is correct.
I did start cycling at around 21:43 and stay stationary for 13+ hours.
( ignore the cycling at 10:57, that’s i got stuck in traffic in taxi. Which is normal i worlds say)
but the imported workout is totally wrong as it shows 2 days 1 hours. If i import that work out, the cycling will last till next day.
I checked the workout in apple fitness app. The record shown inside fitness is correct.
Hmm. Well that’s weird. That “Workout Data” is showing the cycling data (ie the data that came directly from the recorded workout) as spanning 2 days. Which means there’s something wrong in the workout data.
Which I wouldn’t expect from a workout recorded by Apple’s own workout app. And also shouldn’t be possible given the safety check I described earlier (where samples with times outside of the workout’s stated time range are discarded and not imported).
Just double checking the workout import code… yep:
for location in locations {
guard workout.dateRange.contains(location.timestamp) else {
print("LOCATION OUTSIDE WORKOUT DATE RANGE")
continue
}
...
So what that’s saying is that when it imports each recorded sample (the locations) in the workout, it checks each one to see whether its time is within the workout’s stated time range, and if it’s not then it’s skipped.
So there’s something I’m missing here… For the workout to show up in the Fitness app (or Health app) with correct start and end times, it can’t be possible for it to import incorrectly into Arc. Any erroneous samples/locations outside of that range will be discarded. So… how it is ending up with that 2 days duration? I’m at a loss. Hmm.
Nope, I’m not having any bright ideas. And I’m not seeing any clues in the code either. It all looks entirely solid. I can’t see any potential gaps in the logic. I’ll have to keep thinking on it. Anyway thanks for the screenshots! Those definitely help.
