I’m starting to wonder whether the latest Arc updates have introduced a regression. Lately, it feels like I have to manually correct Trips and Places that Arc has recognized perfectly for years.
Here’s a concrete example from this weekend.
Saturday
It was a completely normal day. I drove to do some grocery shopping. Overall, Arc detected my Trips correctly, but it still asked me to confirm that I was driving and to validate several Places that have been known for years. I made the corrections and confirmations, and everything seemed fine.
Sunday
I stayed at Home all day. I only opened Arc to check the date of an old trip abroad. Everything looked normal: Arc correctly showed me at Home.
Monday morning
At around 7:40 AM, I drove to the train station, stopped there very briefly, and then drove straight back Home. Since I know this stop is too short for Arc to create a Place automatically, I opened the app intending to add it manually.
That’s when I discovered something was seriously wrong.
None of my morning Trips had been recorded correctly.
The only recorded Trip was 1 minute 3 seconds long (which later changed to 1 minute 7 seconds) and covered only 53 meters, corresponding to the moment I arrived back Home at around 8:10 AM.
When I tap the Home Place shown below in the Timeline—the one that should normally cover the entire period from my return from grocery shopping on Saturday afternoon until I left Home on Monday at 7:40 AM—the map doesn’t display a Place. Instead, it shows a Trip.
Even stranger, if I open Sunday in the Timeline, despite the fact that I never left Home that day, the map displays a Place located about 1 km away from my actual home.
I’ve attached several screenshots because they’re much easier to understand than my description.
It really looks as though Arc has completely mixed up the Places, the visits, and the Trips. This isn’t just a case of one incorrectly detected Trip—the entire Timeline appears to have become corrupted.
What worries me most now is that I’ll have to try to repair my Timeline manually, and I honestly have no idea how to do that without risking the loss of historical data.
Has anyone else experienced similar Timeline corruption after the recent updates?
I’ve also emailed the latest session log in the hope that it will help you investigate and identify the cause of this issue.
Thanks @siso — the detailed day-by-day writeup plus the emailed log made this properly diagnosable, and the short version is reassuring: nothing is corrupted, and no data was lost. But you did find a real bug, so here’s what actually happened.
First, what your log shows: Arc ran continuously all week — no crashes, no gaps — and on Monday morning it caught your 7:40 departure exactly and recorded the entire drive to the station and back in full detail. The data is all there.
What went wrong is the step after recording: the timeline processing engine incorrectly folded that recorded drive into the long “Home” visit, instead of keeping it as its own trip. That single mistake explains everything in your screenshots:
the Home item drawing as a route on the map (an item draws the samples it contains — and it wrongly contains your drive)
the huge circle sitting ~1km from your home on Sunday’s map (a visit’s circle is computed from its samples, so the swallowed drive dragged the centre off and inflated the size — Sunday itself was recorded fine, exactly as it looked when you checked on the day)
your morning trips seeming to vanish (they’re inside the Home item; only the final minute escaped as that 53m Voiture trip)
We’ve filed this as BIG-625 — your “stopped very briefly at the station” detail is likely the key, and we’ll be digging into how it slipped past the merge rules.
To repair it (a couple of minutes, and it’s the designed cleanup path — your history isn’t at risk):
Long-press the Home item in the timeline and choose “Segments individuels”
Find the drive segments in the list (they’ll show as Voiture, with the drive’s times)
Tap one, then simply select Voiture again — re-selecting its own type extracts it out as a separate timeline item
Repeat if the return leg is listed separately
(Yes, that re-select-the-same-type step is unintuitive — a proper “promote to timeline” button is already on the list as BIG-82.)
On your opening point about more confirmation requests lately: Arc distinguishes unconfirmed (Arc is confident, would just like a confirming tap) from uncertain (genuinely unsure — the purple-dot items). Confirmation requests on their own are normal. But if you’re seeing actually-wrong assignments at long-known places, that would be worth its own report with a concrete example — it’s a different thing from what happened here, and we’d want to see it separately.
Thank you so much for these explanations and for your help in resolving the issue. Following your instructions, I corrected the timeline and everything is back to normal.
It does seem to me, though, that I’m having to make corrections to the timeline more and more often, even though I’ve been using Arc since 2019 and expected to have fewer and fewer corrections to make—especially for very routine things like a trip to the train station, which I take very regularly.
Of course, if I come across another case like this, I’ll forward the log.
@siso Glad to hear it’s all back in order, and thanks for the offer on future logs — as this thread showed, one good log turns a mystery into a diagnosis.
On the corrections trend: noted, genuinely. Your instinct about the direction is right — corrections should trend down as your models mature, not up, and especially not for a route you take regularly. If it keeps feeling like the opposite, concrete examples are the most useful thing you can send: a specific day, what Arc got wrong, and a log if you have one. Each concrete case is diagnosable in a way a general impression isn’t — this thread being the proof.
@siso Following up on BIG-625 — the investigation into how your Monday drive got folded into the Home visit is well underway, and we’ve narrowed it to a small set of candidate mechanisms in the timeline processing engine. One thing would help us pin down which one actually fired: the raw data from that morning.
If you’re willing, the latest Arc update (1.5.0) added a one-tap diagnostics export that captures a full snapshot of a displayed day:
Update Arc if you haven’t already
Navigate the timeline back to Monday July 6
Tap the ⋯ button at the top right of the map, and choose “Exporter le diagnostic”
Tap Continue, then email us the resulting zip (same address as your session logs)
Your repair doesn’t get in the way here — the underlying samples keep their originally-recorded details, so that file still carries the fingerprints we’re after. No urgency on this one; whenever suits.
I’m sending you the diagnostic file from July 6. Since the problem recurred on July 11, I’m including that one as well. On that day, two unknown locations (I’ve never been there) appeared in the timeline. I had a really hard time getting rid of them; they kept reappearing.
