The scheduled background task for updating the activity summaries will update all the summaries that’ve been queued for update, but summaries are only queued for update after you’ve viewed them. This is to avoid the app having to update activity summaries that you never view. For example if you never view weekly summaries, those won’t get queued for updating, saving precious background processing time (of which iOS gives Arc very little allowance of).
Try flicking back and forth between previous and next date ranges of the summaries, to trigger an immediate update. You should see the top part of the summary grey out, which means it’s updating right now. After it fades back in (meaning it finished updating), if the numbers still don’t add up right, let me know! That would definitely be something weird and wrong.
Oh, the top section updates first, then the individual activities beneath each update individually. So you might see loading spinners on some of the activity boxes for a little bit after the top section has finished updating.
Just playing around with my own summaries now, I got my yearly to update to latest by flicking to previous year then back, and it adds up properly (I think it added up properly before that, but I didn’t check properly). My current week is also adding up correctly, but last week’s is off by about half an hour, which seems too large a discrepancy to blame on rounding. I’ll dig into the code and see if I can figure out why there might be going on there…
Not sure if it matters but I’m having the most issues with 2020 and 2021 and the first half of 2022, it looks like 2017-2019 sum up, this might be because I’ve manually viewed the dates in calendar to correct import mistakes so it might also be days that never got viewed in timeline aren’t processed properly
It might be this is only an issue for people who restore from backup and don’t go through every single day for timeline calculations, I just find it odd the yearly map works but the yearly activity doesn’t in which case it might not be worth the time to fix
I need to give this stuff another going over at some stage. I also find it disconcerting, going back to older date ranges and seeing outdated numbers, then flicking back and forth to see if I can trigger an update (which has probably already been queued on first view, but really I want to see it updating immediately, while I wait).
So yeah, if you view an older date range and it looks wrong, it should have been queued for update the moment you viewed it, and should then later end up with correctly updated numbers. But there’s no visual feedback on that “queued for update later”, so you’re left with flicking around between dates until you see it being live updated in front of your eyes. Really not ideal
Ah kindof, it was supposed to be kayaking but I’ve been toggling it back and forth to get this specific 50 minute segment to show up
I can get it to show up if I change one of the start/end points and make it a new activity type.
I can get it to keep showing up if I change it back to kayaking, But if I change the start point back to the original it disappears, and this new activity type is also “infected” with this bug so it no longer shows up.
The activity is also properly calculated when changed to “walking” which also showed up correctly
So it seems to be tied to a specific start / stop journey
It might be that it most frequently occurs with short trips that start and end in the same location because I have quite a few of these in 2020 when my travel was infrequent and I often walked from home to home just to keep active
I do know that occasionally the whole day is recalculated because when the activity summary task is done in arcmini this type of error sometimes disappears
I can’t quite make sense of what might be going on in the background there. A lot of what you describe doesn’t make sense. But then if it did all make sense I’d have found the bug by now and fixed it
In your second screenshot I can see the activitySummaryUpdates hasn’t completed for 9 days, which will be part of the problem. If an activity summary isn’t getting updated in real time while you’re viewing the Activities tab then it’ll get updated later, during that activitySummaryUpdates task. But being 9 days behind means there must be some backlog it’s not getting through.
It looks like you might have monthly auto GPX/JSON exports turned on? Which is also 9 days behind. That task (and the daily auto exports) are the heaviest tasks, taking the longest to finish each day. So it’s likely that that one is chewing up most of Arc’s allotted background processing time each day, leaving not much for the rest. I recommend turning it off for a few days, to see if the others can catch up.
Basically I think there’s two distinct things going on:
There’s some weird bug with the real time activity summary updating that happens while we’re viewing the Activities tab. I think they’re all getting queued up properly, but for some reason the ones we’re viewing aren’t always getting updated properly while viewing, even if we’re on the tab for quite a while.
The activity summaries that have been queued for update should all get updated later, by that activitySummaryUpdates background task. But if that task falls too far behind, we’re going to start noticing more stuff that’s not updated, falling further behind reality.
For problem 2 there’s not much I can do. iOS will do what it does, limiting Arc’s background processing time as its mood takes it, and it can’t be negotiated with.
For problem 1, hopefully I can catch it in the act of being weird, and find the bug! It’s all still looking super random and weird though, as your experiments show. But eventually these things shake out. I have hope
Quick update on this: I forgot to add it to the release notes for Arc 3.7.0, but I’ve significantly improved the speed of activity summary updating in 3.7.0! I’m seeing near instant updating when swiping back through days/weeks/etc now
It didn’t seem to solve the issue with certain activities not being counted though, like on this day car isn’t showing up (again if I change it to a new activity it shows up, but if I change it back to car it disappears)
Honestly couldn’t tell you how to replicate this though since it seems random
That part should hopefully already be accounted for. When it calculates totals for the summaries it fetches all Timeline Items that fall within the date range (either partially or wholly) but for items that bridge the boundaries it only counts the portion of the item inside the range.
But yeah, it seems very likely that I’m not accounting for “bogus”. I bet I added the bogus type after the whole activity summaries system was built.
I went back to the dates of the screenshots posted above and I think your last database fix also fixed those errors, the time seems calculated properly and the missing activity segments are also there, so those might have been fixed indirectly from your last patch
My 2020 though, definitely messed up from all the bogus or missing data from lockdowns
Yeah some of my old data is still messed up too in Activity tab. In my case I think it’s because I recently did a fresh install and full restore from backup.
I think there’s a bug where data restored from backup doesn’t get included in the activity summaries until it’s been viewed at least once in timeline view. Which makes no sense, but that’s what I’m seeing
Yay for building a complex system with lots of moving parts over a bunch of years, then gradually forgetting how each part works
I am wondering how does Arc app handle automatic time zone changes and automatic region specific daylight saving time or maybe leap-days/leap years for all these continuous data recordings and calculations/statistics while potentially travelling across time zone borders with region specific time/date measurement.