Today my Arc Timeline 4 did an automatic update through the App Store. When I opened Arc Timeline 4 on my phone in the evening, it made a data base update. Later I realised, it didn’t record in the tie between the app update and the database update, roughly about 5h. I’m happy I had a look on my phone by chance, otherwise I wouldn’t have noticed at all.
Please integrate some manual CTA to run a data base update, instead of doing the automatic one which causes to gaps. My old Arc timeline App did track all evening. It would also be nice to be able to export the data to Arc timeline 4.
by the way, the data gap is also NOT visible in AT4 - it just extends the stay of the last or next position. How did I even get to this position? not visible at all.
In the old app, it clearly tells you that there is a data gap.
I just had a look into the debug protocols, here are screenshots of the bespoke data gaps (ca. 17.30h to 21.30h)
1 Like
@dagguet you’ve diagnosed this exactly right — nice work reading the logs.
What happened: the App Store auto-update brought a one-time database update with it, and finishing that update held the app up on launch long enough that iOS terminated it before it could complete. You can see it in your own screenshots — the two near-instant sessions at 17:28 and 18:03 are launches that started the update and got killed seconds in. Recording couldn’t run during that window, and only came back once the update finally completed around 21:28. That’s your ~4-hour gap.
This is a real issue and we’re on it (tracked as BIG-440). The right fix isn’t so much a manual update button as making that database step unable to block or interrupt recording in the first place, so this can’t happen silently in the background again. Your log is the clearest confirmation we’ve had that it can cause actual recording loss, which moves it up the list.
Two related notes:
- The gap not showing in AT4 (just extending the neighbouring stay) is a separate known issue we’re tracking too (BIG-444) — your screenshots help there.
- Backfilling that missing window from your old app’s data (which did record that evening) is along the lines of the data-import work we want to get to.
Thanks for catching this and digging into the logs — genuinely useful.
Hi, thanks for you answer.
It happened again today, ca. 16:38 stopped the recording and the there is a data gap (filled with the next location) until ca. 18:20 when I opened the app again. The 2h in between were not tracked - apparently again for some data backup, I could see it in the app there was a backup (and just now, writing the post, it happens again).
Is this now happening almost everyday? I of course love back ups, but I don’t wish it to stop recording. or maybe only backup in stationary mode, when at home, or on wifi, or anything else than when I’m out and missing the data.
below the attached logs of today FYI.
Hi @dagguet, thanks for the detailed screenshots. They make this easy to walk through.
The good news first: the backup activity you spotted isn’t the cause here, and it can’t be. Backups (including the catch-up that works through your long history) only ever run in sleep mode, when the app isn’t actively recording your movement. The moment recording starts, any backup in progress yields to it immediately. Recording always takes priority, so a backup can’t pause, slow, or stop it. The backup you saw and the recording gap happened around the same time, but one didn’t cause the other.
That also means the app already does what you asked for, which is reassuring. It only backs up when you’re stationary and idle, never while you’re out and moving, and never at the expense of recording. So “only back up in stationary mode, and don’t let it stop recording” is already how it works today.
The part actually worth looking at is the recording gap on its own. That looks like a separate issue we’re digging into right now: occasionally recording goes quiet while the app is still running, and picks back up when the app is next opened. There’s a thread following it here: No Movement in AT4 but full day in AT3 — your screenshots fit the same shape, so that’s the best place to follow progress.
(The gap not showing in the timeline, just extending the neighbouring stay, is the separate known one I mentioned last time, BIG-444. Still on the list.)
Same here after the update version.
Thanks @o1x — that fits what this thread’s been tracking. Good news: 1.3.2 went live on the App Store today, and it carries both the fix for the recording gap that can happen around an app update, and a safeguard for the related case where recording quietly stops while the app’s still running. Once you’re on 1.3.2, this should be sorted. If you do still see a gap after updating to it, post here with a debug log from around when it happened and we’ll take a look.
