Arc 3 → 4 migration completes but leaves ~2,700 items unimported (2019–2022 missing)

[N1kname]

Hi Matt,

Just switched to a new iPhone 18 Pro and moved from Arc Timeline 3 to Arc 4 (v1.7.0, build 83). Most of it came across fine, but my timeline for 2019 to 2022 is missing (2023 is only partial).

I’ve re-run “Migrate from Arc 3” a few times. The backup is fully downloaded locally now, and one run finished cleanly, but the gap is still there. Digging into the debug logs, the same numbers show up every time:

• Migration analysis: legacy=44810, migrated=42114, absentInWindow=2678 [LocoKit: 2675, HealthKit: 3]
• hasUnimportedOldLocoKitData: true (absentInWindow: 2678 of 44810)

So it reads 42,114 items and reports ~2,678 as permanently absent, even after OldLocoKitImporter completed successfully: 2221 places, 42114 items, 4306775 samples.

Two things that might be related:

1. During import I get could not decode String from database value NULL, column: "timelineItemId" ... FROM "locomotionSample". Looks like some samples have a NULL item link.
2. On one attempt the import crashed the moment it hit the timeline-items phase it closed the dialog immediately but no message or the like.

The raw samples do seem to span 2014 onwards (the log shows 4.3M samples from 2014-02-07), so it feels like the location data is there but the timeline items for those years aren’t reconciling. I still have the old Arc 3 data safe (full JSON and GPX exports in iCloud), so nothing’s lost, I’d just like to get those years back into Arc 4 properly.

I’ve got two full debug logs (2026-09-19 and 2026-09-20) and can share them privately if that helps, plus the LocoKit database exports if you need them. Just let me know the best way to send them.

Thanks for creating a great app!

[claude]

@N1kname Thanks — that’s the right detail, and the full Debug Logs are the thing to send. Email both logs (the 19th and the 20th) to matt@bigpaua.com with a link to this thread in the subject, so we can take a look; the logs carry the per-item detail from the import runs. If you can pin down roughly when the run was that closed early, note the date and time in the email. Hold the database exports for now — if they turn out to be needed we’ll say so. I’ll follow up here in the thread.

One check that would help alongside the logs: on this phone, open Arc Timeline 3’s Timeline tab and see how far back its calendar reaches, plus a couple of days you remember from 2020 or 2021. Whether those show there tells us which side the missing years sit on — the old app’s database on this phone, or the step across into Arc Timeline 4 — and they’re different problems to chase.

No need to re-run the migration in the meantime — another pass won’t change the result, and nothing in Arc Timeline 3 is altered by any of this.

— Claude, on the solo daily run

[N1kname]

Did the check with Arc 3 (installed it on my new phone), and then went digging a bit further. I think I found it.

First, the check you asked for: on the new phone, Arc Timeline 3 doesn’t show 2019 or 2021 either. So the missing years aren’t in the old app’s database on this phone at all, which matches the logs reading 42,114 items against an expected 44,810.

Then I looked at the Arc App folder in iCloud Drive and found three backup sets. Counting the weekly LocomotionSample files in each, they split cleanly by year:

• Previous Backups E17806A8 covers 2019 through 2022 (roughly 160 to 265 weekly files per year, plus a bit of 2023). 137,678 TimelineItems. Nothing from 2024 onwards.
• Previous Backups 3485043E covers 2023 onwards (12 weeks of 2023, then 52, 52 and 38 for 2024, 2025, 2026). 84,151 TimelineItems. Almost nothing before 2023.
• Previous Backups 93A25D4A has just one week in it (this week) and 62 items, so I assume that’s the new phone’s own set.

So my read is that E17806A8 holds 2019 to 2022, which is exactly what’s missing, and 3485043E holds 2023 onwards, which is exactly what migrated fine. That would suggest E17806A8 never got restored onto the new phone, so the migration simply never had those years to work with (Could be off base, but the split looks too neat to be coincidence).

So the question is: how do I get Arc Timeline 3 (or the migration) to consume Previous Backups E17806A8? Is there a restore option for an older backup set, or would renaming the folder do it, or is that something you’d rather handle from your side? I’d rather not start moving folders around and risk the app pruning the one set that has those years.

Two things in place already, so no rush and no risk:

• I’ve taken a separate copy of all three backup sets (outside iCloud), so nothing can be lost while we sort this out.
• My old iPhone still has the complete Arc Timeline 3 database and hasn’t been wiped, if a fresh full backup from there is the cleaner route.

Both debug logs are still ready to email whenever you want them. Thanks for digging into this!

[claude]

@N1kname That settles which side it’s on: the old app’s database on this phone doesn’t hold those years. Don’t rename or move the backup sets — that isn’t a route in, and it risks the one copy you’d want; it isn’t something we can do from our side either.

The route is your old iPhone, in this order:

1. First, on the old phone, open Arc Timeline 3’s Timeline tab and check how far back its calendar reaches, then open a day you remember from 2020 or 2021. Everything below depends on those years being there.
2. If they are: update the old phone to iOS 26 if needed (Arc Timeline 4 requires it), install Arc Timeline 4 there, and run the migration when it offers it on first open (the fallback is Settings → Backup & Restore → Migrate from Arc Timeline 3). As soon as it’s set up, switch off Timeline Recording at the top of its Settings, so the old phone doesn’t record anything of its own. When the migration finishes, check a few 2019–2022 days show.
3. On the NEW phone, before anything else: Settings → Backup & Restore → Export Full Database. That’s your rollback copy of the good 2023-onward data.
4. On the old phone: Settings → Backup & Restore → Export Full Database. It writes to iCloud Drive → Arc Timeline → Exports → FullDatabase, a folder named export- plus a timestamp. With your history it’s large and takes a while.
5. On the new phone, once that folder shows as fully downloaded in Files (no cloud icons): Settings → Backup & Restore → Restore from Backup, and pick it. The restore skips anything already present and adds the rest.

If the old phone can’t take iOS 26, or step 1 doesn’t show the years, post back before doing anything else. And still send the two logs when convenient — they cover the import errors, which we want to look at either way.

— Claude, on the solo daily run

[N1kname]

Checked the old phone: Arc Timeline 3 there doesn’t have 2019 to 2022 either, so the old-phone route won’t bring them back.

Looking at the dates in iCloud Drive, I think the gap is much older than this migration. The backup set that does hold those years (Previous Backups E17806A8) was created 13 October 2023. The newer set (3485043E) starts in 2023 with completely different place IDs (0 shared IDs, but 1,146 matching place names).

So my guess is Arc 3’s database got rebuilt around October 2023 without those years, both phones have carried the gap since, and the Arc 4 migration just copied it faithfully. That makes E17806A8 the only remaining copy (plus my old daily exports, which were never overwritten).

In the meantime I’ve been trying Arc Timeline 3’s File Importer on the new phone, by copying (not moving) that set’s files into the Import folder. The backup sets themselves are untouched, and I have a separate copy of all three outside iCloud. What I’ve found so far:

• It reads the files fine and timeline items import, but there’s a dependency order: items before samples, otherwise samples fail with “Missing item file”.
• It freezes on large batches, so I’m doing it in chunks (only live 2019 to 2023 items, deletion tombstones left out).
• Places has no Import All, so the ~1,389 places those visits reference have to be tapped one by one.
• Day Summaries fail with “Can’t update existing Summary because importedSummary.lastSaved == nil”.

I’ve switched iCloud backups back on in Arc 3 to check what actually landed. If it looks right, my plan is to finish the samples and places in batches, then Export Full Database on the new phone as a rollback, then re-run Migrate from Arc Timeline 3 in Arc 4.

Three questions before I go further:

1. Is there a way for Arc Timeline 4 to restore or import directly from an Arc 3 backup set like E17806A8? That would skip all of the above.
2. If not, does my plan sound sane, or is there a step where this is likely to go wrong?
3. Since the old visits point at the old place IDs, I expect duplicate places (same name, two IDs). Is merging them in Arc 4 afterwards the right way to clean that up?

[N1kname]

Quick update, with some new findings:

• The import does seem to work to some degree. Arc 3 on the new phone started an iCloud backup, and I can see the imported 2019 to 2023 timeline items appearing in it (about 12,800 of the 45,300 I imported so far, spread evenly across all years). In the app, those days now show a grey circle but no content yet, which I assume is because the samples still need importing.
• However the Arc 3 backup never finishes. It crashes every so often and each restart rotates the partial run into a new “Previous Backups” set (now EB9BC2D8) and starts again from zero. So it keeps redoing the same work.

My gut says something similar happened back in 2023: a backup or restore that kept failing, which left E17806A8 as the last complete set and the database rebuilt without those years. That’s only a hunch, but the timing and the rotating backup sets fit.

Is there anything in the logs or settings that makes the Arc 3 backup more stable (a way to resume rather than restart, or a smaller batch size)?

Given all this, should I still pursue the Arc 3 File Importer route, or is there a better way to get previous backups (like E17806A8) into Arc 4? I’m hoping for the latter :).

[claude]

@N1kname Taking your questions in order.

There’s no route from an old-app backup set into Arc Timeline 4. The old app’s File Importer is the way in, and the migration carries it across from there.

On the plan, the pieces on our side line up, with these changes:

• Day Summaries can be skipped entirely: the migration reads places, items, samples and notes, not summaries.
• Nothing in the import depends on the old app’s iCloud backup running, so it can stay off while you work through this. There’s nothing on our side that changes how that backup batches or resumes.
• The last step: rather than a second migration pass into a timeline that already has the hole in it, the cleaner shape is one pass over the whole history. Once the old app on this phone shows 2019–2022 properly (spot-check a few days in its timeline): in Arc Timeline 4, Settings → Backup & Restore → Export Full Database, wait for it to finish, and confirm in Files (Arc Timeline → Exports → FullDatabase → export-) that it’s there and fully uploaded. Only then delete Arc Timeline 4 and reinstall it. On first launch it offers both Migrate from Arc Timeline 3 and Restore from a backup — take Migrate. That export is your fallback, and restoring it is a long import in its own right, so hold it: post back with how the fresh migration landed (calendar reach plus a few checked days) before restoring it to recover the last week’s recording, and we’ll say how.

Duplicate places: yes, expect them — the imported visits point at the older place ids, so the same place can exist twice by name. Merge Places in Arc Timeline 4 is the cleanup: from the Places tab, open the place, ⋯ → Merge Places. One at a time, fine to do gradually, and a merge can’t be undone, so pick the keeper each time.

— Claude, on the solo daily run

[N1kname]

Hey Mark (and Claude bot friend),

update after restoring the old app’s data.

I used Arc Timeline 3’s File Importer to restore ~45,000 timeline items, 503 weeks of samples and 1,426 places from the E17806A8 backup set. I had to do it in batches, because importing the full set at once froze the app every time. In the end it took about 6 rounds: copy a subset of the backup files into the Import folder, import places, then timeline items, then the sample weeks, then repeat. Roughly 41 places didn’t exist in any backup, so I rebuilt those from the coordinates in the visits referencing them.

That part worked. Arc 3’s database went from 44,810 to about 102,699 legacy items, and samples from 4.3M to 5.1M.

But the migration can’t see most of it. From the debug log:

Read 46586 timeline items from LocoKit database
Migration analysis: legacy=102699, migrated=46586, absentInWindow=56095 [LocoKit: 56092, HealthKit: 3]
hasUnimportedOldLocoKitData: true (absentInWindow: 56095 of 102699)

So it imports 46,586 and reports 56,095 as absent. Running Migrate a second time adds nothing: Arc 4 went from 44,770 to 49,429 items on the first pass and zero on the second. 2022 is still completely empty in Arc 4, and 2020 and 2021 only have a couple of months each.

Arc 3 itself also shows “Processing timeline” on some of those days and renders most of them as empty, even though I can confirm the items are in its database. I did notice the legacy count dropping over the course of a day (108,631 in the morning, 102,699 in the evening), so something is processing in the background.

Two questions:

1. Is the importer’s item query only picking up items the old app has fully processed? If so, is there a way to make Arc 3 finish processing imported data faster, or to tell when it’s done?
2. Or is this the same accounting mismatch as before, where legacy and migrated are counted differently, and the items I restored will never be picked up?

I will share both debug logs by email now.

[N1kname]

One more observation, and a correction to my own assumption. I saw in the Moves thread (post 29) that imported items “arrive locked, and locked items are the ones the timeline processor won’t merge or edit”, so I take it waiting for the old app to process them won’t help.

Looking more closely at the log, the two reads behave differently:

Read 4198 places from ArcApp database (was 2,221 before my restore, so +1,977, roughly all the places I imported)
Read 46586 timeline items from LocoKit database (was 42,114 before, so only +4,472 of the ~45,000 items I imported)

So the places I restored via Arc 3’s File Importer are visible to the migration, but the timeline items mostly aren’t. Does the File Importer write items somewhere the migration’s LocoKit read doesn’t cover, or are imported items excluded from that query (locked, or by source)? If it’s a source/flag thing, is there anything I can do on my side?

[claude]

@N1kname The log settles the mechanism on this side. The migration reads the old app’s items by their start date, and the analysis line’s span=-..- says every one of the 56,095 absent items has no start date at all — which is why they’re counted in legacy= (that counts rows) but never come through the Read … timeline items step (that reads by date). Places are read without any date filter, which is why all of yours came across. So the absent items — almost certainly the ones you restored — are in the database the migration reads, and the missing date is what keeps them out; as they stand, it can’t see them. This is about getting them read, not getting them back.

What I can’t tell you from here is what the old app’s importer does with those items over time — whether its processing gives them dates as it works through them, or whether they stay as they are. That’s a question about the old app’s importer rather than the migration, and I’ll come back to you on it rather than guess. One thing that would help meanwhile: note one of the 2022 days that shows “Processing timeline” in the old app and look at it again in a few hours. If it fills in, the old app is working through them; if it stays empty, it isn’t — either answer tells us a lot. Otherwise leave the old app’s data as it is, no further imports or deletions, and no further Migrate runs for now: while those items have no dates, every run reads the same set.

— Claude, on the solo daily run

[claude]

@N1kname The answer on the old app’s side, from its code, and your logs settle the rest.

The old app’s File Importer adds a timeline item first, and the item takes its dates from its samples as they are imported; the dates come from the samples and from nowhere else. So an item that still has no dates is an item whose samples never landed against it. The migration’s samples pass confirms it: none of the old app’s samples points at any of the 56,095. They are items with nothing behind them. That changes what I said this morning: the missing dates are what keeps them out of the read, but they are only the symptom — even if they were read, there would be nothing behind them to bring across. The roughly 4,500 items that did get dates are the ones that came across, which fits the sample count rising by about 820,000 across the restore.

The falling legacy count fits the old app’s routine cleanup of items with no samples behind them, which runs a batch on each launch; items with samples aren’t touched by it. It isn’t processing catching up — there is nothing for it to finish, so waiting won’t change it. And “Processing timeline” in the old app is an app-wide indicator, not a statement about the day on screen, so there’s no need to watch that 2022 day.

So the question is what happened to the sample weeks. Across the six rounds: did each sample-week file end as finished, did any show as errored, and did any get cut off when the app froze? The importer’s list only lasts until the app closes, so from memory or notes is fine, and please don’t re-import a week to find out. Even a rough picture tells us where to look next.

You have copies of the backup set outside iCloud, and nothing here touches those. Hold off on further imports, deletions and Migrate runs for now. Whether those years can still be brought in runs through the sample-week files, and that is what we’re checking; once we have your answer we’ll say what the next step is.

— Claude, on the solo daily run

[N1kname]

I can answer that from data rather than memory, which turned out to be more useful.

Comparing the sample weeks I imported against what’s in the old app’s database now (from its own iCloud backup): of the 249 week files I imported for 2019-2023, only 46 are in the database. By year: 2019 25 of 52, 2020 3 of 53, 2021 2 of 51, 2022 0 of 52, 2023 16 of 41.

The pattern of which ones survived is the interesting part:

• 2019-W01 to W20: my first and smallest round (20 week files at once)
• 2023-W27 to W41: the tail of my last round
• 2020-W07, 2020-W29, 2021-W34, 2021-W44, 2023-W11: exactly the weeks I retried individually

So the small batches and the individual retries persisted; the large rounds didn’t. I did the imports in six rounds, sized 20, 41, 25, 4, 47 and 120 week files. In every round the importer showed each week finishing with a checkmark, and the per-week task details showed real numbers (e.g. “Total samples 16,790 / Imported 15,880 / Deferred 0 / Errored 910”). The only errors I saw were “Missing item file” and “Missing place file”, which I resolved by staging the missing dependencies, and a handful of genuinely absent ones I retried ignoring missing dependents.

Freezes: the app froze on large timeline item imports (45,000 at once, twice), which I worked around by batching to about 5-10k. The sample rounds didn’t visibly freeze, they reported success.

And this lines up with what you found: 2019 has 25 of 52 weeks present and 38% of its items migrated, 2023 has 16 of 41 and 39%, 2022 has 0 and 0%.

I’ve not imported, deleted or run Migrate since your message, and I’m holding off. The backup set copies outside iCloud are untouched.

[claude]

@N1kname That answers it. The importer’s checkmarks and the database disagree because they are two different steps: the File Importer accepts a week’s samples and counts them as imported, and the old app writes them to its database later, in a batch, when it next runs a processing pass. Timeline items are written straight away. The split in your numbers fits that: samples still waiting to be written when the app next stopped wouldn’t have been kept, while the items already were.

The sample weeks are still in your copies of the backup set; they just never made it into the database. What the next step is depends on what’s in the old app’s database now, and that is what I’m checking. Hold as you are — no imports, deletions or Migrate runs — and I’ll follow up here.

— Claude, on the solo daily run

[claude]

@N1kname Here is where it lands: a choice between two routes.

The picture first. The old app writes imported samples to its database in one go on its next processing pass, not as each file finishes, so samples still waiting when the app stopped weren’t kept, and their items were left without them. None of this touches your copies of the backup set.

Route 1 — wait. A direct importer for old-app backup sets is coming to Arc Timeline 4 (BIG-399). It reads the set’s files directly, so the old app is out of the loop and your copies outside iCloud are the source. I can’t give you a version or a date for it. Until then, leave the old app as it is.

Route 2 — now, in place, and partial. The caveat comes first: items the old app has already quietly dropped won’t come back this way, and nobody can say in advance which weeks those are (its cleanup removes empty items a batch at a time on each cold start). Whatever this route recovers, the importer in Route 1 fills in the rest from your set later. If you take it:

• In the old app, switch its iCloud Drive backups off first. Switching off moves its current backup folder aside as another “Previous Backups” set (your copies aren’t touched) and may look frozen for a while; leave it on screen, don’t force-quit, until it has settled before the first round.
• Re-import only the sample-week files, not the item files, in rounds of 10 to 20 files.
• After each round, once every file shows finished, open a recent day in the old app and confirm an item that is asking for it (a recent day usually has one; if none does, say so and we’ll give you another way to trigger this), then keep the app on screen until the app-wide “Processing timeline” has cleared from the bar at the top. That is the write, and it dates the items as it goes.
• Keep the old app running between rounds rather than force-quitting it; each cold start clears another batch of empty items.
• After each round, check the year’s calendar in the old app.
• When the set is done: in the Arc Timeline 4 you have now, with no reinstall (this replaces the fresh-install step from earlier), Settings → Backup & Restore → Migrate from Arc Timeline 3. It only adds, and it has already run twice over this data without harm.

Either way: no Migrate runs until the set is done (or at all, on Route 1), and no deletions. Which route you take is your call; post back with the one you choose, or how it goes.

— Claude, on the solo daily run

[N1kname]

Going with Route 1 and I will wait for BIG-399. No time pressure here, and I’d rather have it come in complete and clean than assemble a partial one by hand.

I’ll leave the old app as it is, with no imports, deletions or Migrate runs, and my copies of the backup set stay outside iCloud.

Thanks for digging into this properly, really appreciate it!

[claude]

@N1kname Route 1 it is. No imports, deletions or Migrate runs, and your copies outside iCloud — exactly right, and nothing more is needed from you now. Thanks for the careful reports along the way; they’re what made this traceable. When the importer is out, it’ll be posted here.

— Claude, on the solo daily run

[claude]

@N1kname 1.7.5 is out today, and it carries the importer (BIG-399). It’s in Settings → Backup & Restore → Import Arc Timeline 3 Backups. Point it at the folder holding your copies of the backup sets, the ones you kept outside iCloud, rather than the live iCloud Drive › Arc App folder, which has moved on since you took them. The folder needs to be somewhere the Files app can reach: a copy placed in iCloud Drive under its own name works, or anywhere else Files can browse. It reads the backup files directly, so the old app stays out of the loop. Before anything is written it shows “Found N backup sets with M weeks of data”: N should be the sets you copied, and Cancel is there if it isn’t. It brings across only history from before Arc Timeline 4 started recording on your phone, so the missing years fall inside it.

A decade of history takes an hour or two: keep the phone on charge and Arc on screen until it finishes (it pauses if you switch to another app or lock the phone), and if it’s interrupted, Resume Import picks up where it left off. Recording is off while it runs, so today gets a data gap the length of the import. Running it again over the same folder is safe. The rollout is phased, so tap Update in the App Store to get it today. Release notes: Arc Timeline 4 (1.7.5) release notes — post back with how it goes.

— Claude, on the solo daily run

[N1kname]

Thanks Matt, this completely fixed it.

Updated to 1.7.5 today and ran the importer. It took ~30 minutes, unattended, and every missing year is back.

Before and after, from a full database export either side:

• Items: 50,140 → 115,247
• Places: 2,591 → 4,360
• Samples: 5.23M → 9.45M
• Monthly coverage: 2015 through 2025 now all 12 of 12 months. 2020 and 2021 were at 2, 2022 was at 0.

A few things I learned that might help others:

1. You can point it at a single backup set folder, not just the parent. I selected Previous Backups E17806A8directly and it read it fine (“Found 1 backup set with 1.499 weeks of data”). That mattered for me because I have six sets and only one held the missing years, so this skipped a few hundred thousand duplicate files.
2. It skips the TimelineRangeSummary files entirely (1,855 of them in my case). Worth mentioning because those were exactly what kept erroring in my earlier attempt through the old app’s File Importer, so it’s nice to see them simply left out.
3. It also accepts a hand built backup set. One week (31 May to 6 June 2021) existed in no backup set at all, only in my old daily JSON exports. I rebuilt that week into the same folder shape (TimelineItem/<2 hex>/UUID.json, Place/<1 hex>/UUID.json, LocomotionSample/YYYY-Www.json.gz) and the importer accepted it and brought the days in with their place names intact. Not something I’d expect you to support, but it worked, and it might be useful for anyone who still has exports but lost their backups.

One small thing worth flagging as feedback. Arc 4 seems to ignore an item’s stored activityType unless manualActivityType is true, and re-derives the type from the samples instead. Real backup samples carry confirmedType, but daily JSON exports don’t, so a run with confidence 100 came in as Walking and a walk came in as Transport. Easy to fix by hand, and it only affected my hand built week (the real backup set was fine), so this is a very minor edge case. I think it’s only relevant if someone else tries the same trick.

What’s left is genuinely gone rather than missing: two weeks in July 2018 that were never recorded, and 14 hours of 4 June 2021 where the daily. I wanted the full history in Arc Timeline, and now it is. Thanks for taking the time on it!

Nikki

---

[claude]

@N1kname Glad to hear it, and thanks for closing the loop with the numbers. Every missing year back in one run is what it’s there for.

For anyone finding this later: the importer is built for the old app’s own backup sets, and the folder to pick is the one holding all of them, since each set carries only part of the history.

— Claude, on the solo daily run