I am having an issue for some time now. After going somewhere, stay there so it becomes visit, and then continue moving after the visit, Arc stops recording for a while, and it assumes a large part of the track after the visit belongs to that visit.
Let me show you some screenshots.
I am living in the southern part of the screenshot. I went for a walk in north-east direction, then west. There I visited a grocery store, and then walked back home.
As you can see, the last part from the grocery store to home is missing a large part. Also a small piece of the track just before entering Albert Heijn is missing.
This is what I see when I tick Albert Heijn. It shows the correct final path to Albert Heijn and me walking in the store. It also shows a long direct line to my home, there are no recorded points, and is not correct.
I can make the situation better by deleting the Albert Heijn visit, and then insert a short stop, but that creates a direct line from Albert Heijn to almost home, which is not correct.
Hi @vogon1! Yeah I’m tracking a similar (probably same) problem on my own phone too. Have been observing it over the past few days / week, to see if I can figure out what the pattern is.
My current hunch is that it’s due to Sleep Mode being held onto too aggressively. It’s possibly being too eager to read new incoming location data as within the current stationary radius and staying in sleep mode too long.
That will result in fewer incoming location updates being requested, fewer samples being recorded, and the filtering more conservatively reading each one as being closer to the previous visit than it should.
I’ll hopefully have some improvements ready for this soon!
After a few days of using beta 25, I am quite happy, it is a lot better now!
But I think it is getting out of sleep just a bit too late, the first part after a stay somewhere still makes a short-cut.
If this is it - fine, I can live with it. But it used to be a bit better.
For that remaining sluggishness in wakeup, I’m guessing that’ll be due to the leaving probability being low and sleep cycles being longer. Which will improve as it learns more about that particular place.
The fix in build 49 is such that as long as a wakeup check has started, it’ll figure out whether you’re genuinely moving or not before going back to sleep. So it’s now as rapid in restarting recording as possible, without further shortening the sleep cycle durations, which would hurt battery life.
Oh there’s one more fix coming in the next build though! A separate problem, but that presents the same way. In some cases iOS has been stopping delivery of new location updates to the app, for tens of minutes at a time. The next build has improved resiliency for that, effectively pestering iOS until it does finally deliver a new location. Sort of. Anyway yeah, next build will be even more robust
