Since the last update (which may have been around the same time as my update to iOS 18 now that I think about it) I have many problems. Off the top of my head:
I need to spend a lot more time cleaning up the timeline (not because of the new interface, just because many places are not recognized, or stops are not detected in a route. making changes in the timeline also often triggers an automatic update that takes a long time to finish.)
the app often opens to a black screen, I have to kill it and restart it then
sometimes the app opens to a white screen. that mostly solves itself after a few minutes but nothing gets recorded in that time.
I often see track that are much longer than they should be, often this is because of jumps on those track. (difficult to explain, I’ve included a screenshot)
1 very strange issue: a 2 hour stay at home contains within it a trip to pick up my kid from school (a few kilometers) and there is no way to split this out.
sometimes when I am in the timeline view and want to go 1 day back with the left arrow, that arrow just disappears, need to kill the app to get it back
my home location is often not recognized, stays as Unknown Place but when I click “edit”, Home is the first suggestion and the only one without a distance. (this is actually not new, the app has done this for as long as I can remember)
timeline items are not unique. 1 example from today: I stayed at work from 8:49 to 12:04 (3h15m) and also from 8:54 tot 12:04 (3h10m). why is this not just 1 visit?
Some context:
this is on an iPhone 13 mini running iOS 18
Arc recorder is running in the background
I have been using Arc since 2018 (can a lot of data cause issues?)
I have 2 automations running: each morning iOS automatically starts Arc and I let iOS automatically start Arc whenever I connect to CarPlay. (this was because the app was often killed by iOS in the past and I lost a lot of data before discovering that. Maybe less needed today, but I don’t think it can hurt.)
(sorry that I updated my app review for this, I should indeed have come to the forum first)
That’s a lot of problems. I’m not sure if they’re all related or not, so I’ll work down the list in order and see if I can make sense of each. Though most of them are quite unusual, so I’m not sure that I’ll have good answers. Anyway, diving in:
The first two issues - needing lots of cleanup / incorrect place and trip detections / long processing times, and the app opening to a black screen, those two issue clusters sound related to me. The latter being a result of the former. It sounds like Arc is getting bogged down doing processing, struggling to make sense of the timeline data, which is sometimes creating a backlog and potentially making the app freeze up for periods of time. That could then result in the app taking too long to “grow a head” (build its UI) when it comes into the foreground. The opening to a white screen, likewise probably a variation on the same.
Your screenshot with what appears to be two diverging paths but within the same time period… that looks like it’s the result of two apps recording at the same time. Are you also running Arc Mini or Arc Recorder? I think from your App Store review you mentioned Arc Recorder? If so, make sure it’s updated to the latest version.
There was a communication issue between Arc Timeline and Arc Recorder in the very first Arc Recorder release, which was fixed in the subsequent update. You should have v1.0.1 installed. Without that update, sometimes the apps could end up both recording at the same time, without realising, and creating weird double ups like that.
This also sounds like it could be the result of Arc Timeline and Arc Recorder clobbering each other, trying to record at the same time. So yeah, hopefully it’s just a case of Arc Recorder not being up to date! If however you are already on Arc Recorder 1.0.1… there’s a deeper mystery, and one that I don’t have any good ideas about yet.
Most of the problems you’ve described so far could potentially be a result of the two apps trying to record at the same time. When they do that they can create really weird timeline data that the processing engine can’t make sense of, which could result in it churning away trying to process it but failing, and potentially also making a bigger mess. Which could then result in the app running slower, freezing, etc.
Well that’s odd. I’ve never seen that before. Although… I guess that could be another symptom of the timeline processor getting bogged down, and blocking other things from happening while it’s churning away.
Hmm. This one could be something separate. Although the fact that it says as Unknown Place instead of having a different incorrect place assigned, that’s pretty weird. Usually when someone’s Home place doesn’t get correctly auto assigned it means there’s another nearby place in the list that’s accidentally had some visits confirmed that should’ve been assigned to Home instead, which then confuses the place classifier, causing it to be uncertain and then sometimes make the wrong choice.
But for it to stay with Unknown Place… I wonder if this is related to the clogged up timeline processing / messy timeline data. If Home the only place in the list that’s got no distance noted (which means it’s directly overlapping the visit, ie a perfect geographical match) then the place classifier doesn’t have any decision to make - there’s only one option that fits, and it should always choose it. For it to choose nothing (ie leaving it as “Unknown Place”, meaning no place assigned) … that indicates that the place classifier hasn’t even had a chance to do its job.
Ok this also sounds like a likely symptom of the Arc Timeline / Arc Recorder recording clash, with both trying to record at the same time. They might create separate visits, which should then get automatically merged, but the processing engine might in some cases not be able to make sense of it, thus leaving a mess like that.
I really hope it’s just a case of Arc Recorder being out of date! Because that could explain almost all the problems, and with that update hopefully fix almost all of them! If Arc Recorder really is already up to date… there’s some very weird gremlin activity going on.
For these, I’m guessing they’re just safety catches, to get it started in cases where iOS might have killed it? You’re not actively swiping it closed yourself? If so, then they seem fine to me. Though having Arc Recorder also running should protect you from data gaps, given that it runs with an extremely low memory profile, making it very unlikely to be killed by iOS. (On my main phone Arc Recorder has been running for over a week uninterrupted).
Ok, so, fingers crossed it’s just Arc Recorder being out of date If that’s not the case… I might have to send you a debug build with debug logging, so we can do some testing and get some logs to see clearer what’s going on under the hood. Because yeah, it’s pretty weird behaviour!
Oh, don’t worry about that. It’s pretty common for people to have 6+ years of Arc data. The app should cope fine with that under normal conditions. For most cases, it only needs to actually load a small portion of the data at a time, eg just the current day when viewing the day timeline view - that kind of thing.
There are some scheduled housekeeping tasks that run overnight that can churn through a lot more data, but they’re all optimised to cope with large databases with many years of data. My own database goes back to 2016, and until recently my main phone was an iPhone 13 Pro, which was never stressed by it.
Oh, if you’re also running Arc Mini, ditch that. No need for three apps running. Arc Timeline and Arc Recorder work well together, and should be enough to protect from data gaps.
If Arc Mini is also in the mix, there could be another communication breakdown. Though I’m not aware of one with Mini at the moment, but it isn’t entire implausible.
Thanks for the fast and extensive response. I do keep all apps up to date so Arc Recorder is at 1.0.1.
I don’t use Arc mini that often but when I do, I don’t think I kill it afterwards so I have now done that and uninstalled it. So now it’s just the main Arc app and Arc recorder running. I’ll give it a few days like that.
Would other apps using location interfere? like apple maps or waze? I guess not as that would be quite common.
Ah, hopefully that was it! I’m betting Mini was having a communication fail with the other two, and trying to record over the top of them, creating messy timeline data that the processing engine was becoming endlessly confused by.
Aside: Swiping any of the Arc family of apps closed will only stop them temporarily - they’ll get auto restarted by iOS some minutes later (most of the time - it’s not guaranteed to happen).
Those should be fine. The only interaction with other location / navigation apps that I’m aware of is CarPlay and/or Google Maps navigation sessions while plugged in to power in a car, which for some reason can overload things and cause Arc to get terminated.
My assumption in that case is that it’s either a memory use thing or a device temperature. It seems that if the phone isn’t plugged in there’s less risk of termination, so that leans towards the device temperature theory - phones heat up when they’re charging, and navigation sessions request the highest location data accuracy (higher than Arc requests), which means higher sampling rate, higher CPU usage, and higher device temperature.
I think uninstalling Arc Mini solved my issues. I have been using it like that for 2 weeks now and most problem are gone. Occasionally I open Arc and see the logo screen first (I think that is a case of Arc having been killed).
I remember only 1 case of Arc opening to a black screen and then not responding. After restarting it it seemed to have lost a ~30min drive and when I switched to Arc Recording and tried to access the logs that one crashed too. I restarted both and after a while that 30 minutes drive was added.
I do think that the 4GB memory of the iPhone 13 are starting to be an issue (maybe since the iOS 18 update?). My typical use case in the car is Apple Maps + CarPlay + Arc + Overcast (podcasts). Most of the time that works but occasionally either Arc or Overcast seems to get killed.
(I’ll be restoring my review as well, that seemed a bit of an ashosle move, sorry about that.)
Hijacking the thread a bit to report my own two issues since the big update.
Persistent “Thinking…” Segments: There are quite some “Thinking…” segments that don’t resolve, sometimes hanging for days / since the update. This makes retrospective classification difficult, as these segments can’t be confirmed or edited while they’re stuck in this state. (Re-)Confirming/changing segments before or after the “Thinking…” ones doesn’t seem to help.
Place Classification Issue: When I try to classify/change unknown/wrong places (see attached image), tapping “Edit” and selecting the correct location (e.g., “H Haltepunkt Dobritz” in this case) causes the process (not the app) to freeze. The font greys out, but it never completes, even after letting it run for over 40 minutes with screen lock disabled as a test. Pressing back sometimes shows the location has indeed updated anyways, but other times it hasn’t, requiring multiple (often >20) attempts.
For reference, I’m on an iPhone SE (2nd gen), iOS 17.7, which doesn’t have the highest performance. Wondering if the latest app update requires more resources than my device can handle, slowing down or preventing Arc from completing these tasks?
Yeah that’s my way of knowing that Arc had been killed too. If it opens showing the logo/launch screen first, that almost always means it’s a fresh launch. Though I have very rarely seen the logo/launch screen appear when the app is definitely already alive - so it’s not 100% certain test. But typically it does mean it’s a fresh launch.
Ah ok. Sounds like one of them was alive to record it then, but perhaps the data just hadn’t been processed yet. Which would make sense for Arc Recorder having recorded it. Arc Recorder is much more conservative about processing timeline data, to reduce energy/battery use as much as possible.
Arc Recorder will let the new data stack up unprocessed, leaving that job mostly to Arc Timeline instead. So if there’s a bunch of data from Arc Recorder then it might take a moment to show up properly once Arc Timeline gets to processing it.
Could well be the case. With all new iPhones being 8 GB, chances are Apple are pushing iOS 18 to be more memory hungry. Which is going to hurt the older phones with less RAM.
I recently switched from a 13 Pro to a 15 Pro for my main phone, but I still have the 13 Pro everywhere with me for testing. I’ll keep an eye on it. I haven’t noticed anything yet, but now that that phone is just a secondary test device it’s not doing anything other than Arc, so it’s not quite a “normal use” test anymore.
Hah. Thanks!
Yeah, it’s much easier to deal with issues on the support forum - there’s often a lot of detail to work through, back and forth, trial and error. I’m not fussed if people point out things they don’t like in App Store reviews - that’s what they’re for. But if it’s anything that can be resolved with a bit of testing and detective work to work through the problem then we’re much better off dealing with it here on the support forum.
The latest update didn’t change anything fundamentally - it only introduced that new bit of UI for group confirming items. So it shouldn’t be a case of of it requiring more memory or CPU or anything. It’ll likely just be a coincidence that the problems started around the same time.
It’s also curious that you’re on iOS 17.7, so we exclude iOS 18 as being the source of any problems either. That also makes it seem more coincidental, and not related to any software updates.
For these, there’s two different possibilities.
To give a little background first: The timeline view shows “Thinking…” when there’s one or more very short/brief timeline items. If they’re too short to qualify as “keeper” status, then they’re very likely to be removed shortly by the processing engine, being merged into an adjacent item. So instead of showing a potentially cluttered list of nonsense little items that will soon disappear, it shows “Thinking…” in place of them, to keep the list a bit more tidy.
Now, the two different possibilities are:
Those brief items aren’t getting cleaned up by the processing engine because the processing engine is backlogged and having trouble getting through its workload, or…
The processing engine is managing to work through them, but it’s getting left with one little item that it can’t clean up, due to it falling into a gap in the processing rules, which means it ends up getting left in the timeline. In that case it’s not meant to show “Thinking…” anymore, it’s meant to just show that little item as it is. But there’s a UI bug that makes it sometimes still show “Thinking…” even though processing has finished.
This freezing makes me think the first case above is the more likely one - that there’s a backlog of processing, and the processing engine is getting bogged down in the workload, falling behind and slowing everything else down.
With that in mind, we’d best start trying to debug why the processing engine is falling behind in its workload!
First thing to check for, which seems to be popping up as a common cause now (though I’m still not sure why) is Arc Mini. If you’ve still got Arc Mini installed, best to uninstall that, and use Arc Recorder as the fallback recording app instead.
I don’t yet understand why Arc Mini would be causing these kinds of problems. But yeah, there’s enough reports of it now that it’s fairly certain to be causing this kind of problem.
If you don’t have Arc Mini installed, then… we’ve got a different mystery to solve, and have to start looking for clues in recent patterns, locations, etc in the timeline data. Basically something weird has got into the timeline data for some reason, and the processing engine is failing to deal with it. The question is how it got there and what it is (assuming it’s not the result of Arc Mini doing something weird).
First of all: Thanks, Matt, for the fantastic support and community work - much appreciated!
I do indeed have both the base Arc App and Arc Mini installed. My main reason for this setup is to avoid the location indicator of the Arc Recorder app, which I find visually intrusive (as you probably know and can see in the screenshot). The indicator bar not only acts as a big visual “annoyance,” but it also disables the “tap clock to scroll all the way up” feature in iOS, which I use a lot. On top of that, I really like the “Promote to Timeline” button in Arc Mini.
(I do know that the indicator bar is an iOS/Apple topic, not specific to the Arc apps.)
That said, I’ll switch to running Arc App + Arc Recorder for a while, removing Arc Mini, to see if this helps reduce any backlog buildup and resolves the issues. Will post an update here soon. Thanks again!
I might have found the culprit. Going back through the days since I updated Arc, I found this one day with a large number of unprocessed items. I’ve observed it for a while, and the number of pending items hasn’t decreased. Since this day is already two weeks old, and I typically have the app open regularly (with it running in the background almost constantly), it seems like something might have gotten stuck there. Could this backlog be causing the processing to hang up?
Yes, that is incredibly annoying! Apple have made a choice there that makes the phone’s UX worse, and no longer offer any way around it. It’s a long running source of friction in the relationship with Apple, for me.
I’m not sure if you’ve seen my explanation for why Arc Recorder doesn’t offer an opt-out on that bar yet. But the basics of it is that Apple are phasing out the ability for apps to opt out of it, and making life worse for apps that do still allow an opt out.
Arc Timeline app has that setting for turning on/off that annoying bar. But if you turn it off, Arc Timeline (and Arc Mini) have to record less efficiently, and also at greater risk of termination. So it’s on the cusp of being no longer viable.
Apple have also removed that bit of API from their most recent location recording APIs, which are what Arc Recorder uses. So they’re giving multiple signals of “don’t keep doing this; and if you do keep doing it, we’re going to make life increasingly difficult for you”. I’m really not happy about that!
Oh thanks for the reminder! I need to add that button to the new Arc Editor app that I’m currently building (which is a group up rebuild of Arc Timeline app, to get rid of a decade of cruft).
You can still achieve the same result in Arc Timeline, by just choosing the same type in the types list for the segment, as though you’re “changing” it to the type it already is. That does exactly the same as “Promote to Timeline”, albeit in a much more ambiguous and non-obvious way.
Hmm. Could be! Although I’m suspicious. Typically the timeline processing engine is only busy working on the visible timeline, eg if you’re viewing today, it’ll be trying to process/reprocess the items from today. Though it will also be doing some minor processing on the previous/next day, because the UI preloads previous/next days to make swiping back and forth faster.
28 October should be too far back to still be getting any attention from the processing engine. Though at the same time, one of the reasons why I’m building Arc Editor app as an eventual replacement for Arc Timeline app is that Arc Timeline really has become overly complex under the hood. Over the past almost-decade a lot of technical detail and technical debt has built up, to the point where I’m often not completely sure what’s going on, what the app is doing, etc.
So it’s entirely possible that there is some reason why it might be trying to do some processing back that far, and I’m just not aware of it! Maybe I wrote some feature or improvement five years that I’ve completely forgotten, that has the side effect of causing that to happen
So yeah, it will still be worth trying to clean that day up somehow, on the off chance that it’s causing flow-on problems for processing on other days. Though if the number isn’t going down on its own … that presents more of a challenge. If there are any visible timeline items in that day that you can plausible confirm or edit in some way to somehow make things tidier or less ambiguous for the processing engine, that might help things along. Maybe the processing engine has got stuck on one particular confusing cluster of items and isn’t managing to find a way forward.
Yes, I’ve read that thread, and it makes sense to me. I even reached out to Apple at one point to share my perspective on this as a customer. I get the data protection and privacy angle, but something like the Shortcuts approach - where the user is notified about enabled Shortcut automations after each device restart - or a one-time/restart confirmation for specific apps to use background location without constantly showing the blue bar could be a fair compromise between privacy and developer flexibility. But I suppose Apple won’t change this unless they get significant feedback on it.
I had this turned off in Arc Timeline before, but since Arc Recorder forces the blue bar anyway, I’ve enabled it in Timeline too. Statistics are still low, of course, but this has already noticeably decreased forced terminations.
This is really insightful, thanks! I had assumed that the engine started with the current view/day and then moved backward, clearing unprocessed data step by step. What’s the best approach in cases like mine (with unprocessed data going back two weeks)? Should I start with today, clean that up, then swipe back one day, let the engine process, and repeat the process day by day?
I’ll go ahead with that. It’ll take some time, as confirming or changing anything on that day tends to be slow, and the app sometimes crashes mid-process (which sometimes reverts previous changes - possibly because they weren’t fully saved before the crash?).
One thing I can already report: since switching from Arc Mini to Arc Recorder, the newly recorded data looks significantly cleaner.
Yes exactly. They don’t need to put something at the top permanently to get the message across. It’s grossly excessive. They could also offer a setting for each app, to disable the warning/indicator per app.
Yep. And we’re too niche to have much impact or get any attention on it. Though hopefully there’s enough other apps having the same problem that Apple will eventually pay attention. I’m not hopeful though.
It got even worse in iOS 18 in terms of extra terminations when that setting was turned on. (Though it could’ve been just coincidence - hard to piece apart coincidences from genuine effects a lot of the time). I might have to remove that option in Arc Timeline eventually. It won’t be in Arc Editor (the Arc Timeline rebuild) either. Unfortunate.
My instinct is to start with the most recent and work backwards. Though it might not make a lot of difference either way.
I suspect if I were doing it myself I might end up hopping between days, trying to confirm/correct anything I could see in any of the target days, then waiting for the processing engine to hopefully do some of its own cleanup around that change.
When you make an edit or confirm or correct something, that fires off a task to the processing engine, “reprocess starting from this point and looking outwards”. So it’ll collect up the edited item then a few adjacent items on either side, and look to see if there’s any merges/cleanup it can do. And then keep working outwards from there until it can’t see any more possible cleanups that match its rules.
So sometimes if the processing engine runs out of possible cleanups at one point in the timeline, you can do some manual cleanup somewhere else in the day and then that’ll flow back to that first point, rearranging things in such a way that the processing engine can now see cleanup possibilities it couldn’t see previously.
Yeah, pretty much. All of the editing/processing/cleanup is done one at a time in a “serial queue” instead of parallel. The reason for that is to reduce the chances of the processing engine trying to do its work over the top of what you’re doing yourself, or the other way around. All edits get put in the queue and applied in order, to avoid weird clashes.
But that has the side effect of creating backlogs sometimes, where there’s a bunch of edit tasks been put on the queue, and some of them are taking too long, so the most recent ones are left sitting in the queue waiting to happen, not yet properly applied. If the app gets terminated while there’s still work in the queue…
That’s basically the cause of the various slowdowns and sustained messes. That “serial queue” / one-at-a-time system maintains an orderly, semi-predictable application of automatic and manual edits and cleanups, but also creates the risk of backlogs and slowdowns. It would be much faster if Arc did all the processing in parallel, but it would also be much less predictable or reliable - much more chaotic.
Aside: In Arc Editor app I’ve managed to do those processing loops a bit better, and more efficiently than how they are in Arc Timeline app. The fresh code has allowed me to get rid of a bunch of inefficiencies, and the results are also more reliable and predictable, with more strict application of structural rules, etc. It’s still a serial / one-at-a-time system, because that’s still necessary for maintaining sanity when there’s possibilities of different kinds of edits clashing, but it is nicely improved. I’m really looking forward to getting it shipped, hopefully soon!
It took a while and was a bit tedious, but I managed to clean up the 28th and all the other problematic recent days. It seems like this helped the processing engine run much smoother again. Over the last few days, I’ve encountered far fewer issues (though I haven’t been moving around much).
The combination of Arc Timeline and Arc Recorder does seem to work much better than with Arc Mini - I suppose the blue bar is a reasonable price to pay for that improvement.
I do still have a few minor issues:
On one day, I have two “car” trips right after one another that won’t merge. Everything is confirmed for that day, and each trip has been cleaned up so that they contain only one car segment each. I also tried reconfirming both segments, but they still won’t merge. Is there anything else I can try to resolve this?
This feature works only sometimes for me. Are there specific conditions (e.g., minimum distance or duration) that decide whether an item can be promoted to the timeline?
Occasionally, the sleep geofencing seems too loose. For example, when I leave my home, the track sometimes only starts recording when I’m already 500-800 meters away. The orange “confidence” circle around my home is quite small (about 30 meters in diameter), so it seems like Arc knows quite well if I am at that location. In Arc Recorder, I noticed the sleepCycleDuration parameter - does this define how frequently the position is polled in sleep mode?
Ah, this one. So… it might not be possible to merge them. It will depend what the cause is. There’s two possible causes that I’m aware of, both of which I consider to technically be bugs.
The first one is a weird processing quirk that I haven’t been able to find the cause of, but that you can work around most times by splitting off a piece at the end of one of the items and giving it some random activity type. Like say split off a bit of “motorbike” between the two items, just temporarily, so that it ends up “car → motorbike → car”. Then when you go to change that motorbike back to car, mysteriously the processing engine is happy to merge the three items together, even though it insisted that it couldn’t merge the previous two car items together
The second bug is a new one introduced recently, when I “fixed” a processing rule that I discovered had never been getting applied. The rule is one that rejects merges that aren’t physically possible. By that I mean it looks at the speeds of the two items and the distance of the gap between them, and calculates whether it would be physically possible to actually cover that distance at around that speed. If not, then it rejects the merge.
I gave that rule a lot of room to move, in that it will consider speeds up to something like 5-10 times the speed of the fastest of the two items. So in almost all cases it should still allow the merges, even if technically they don’t really look plausible mathematically / physically. Data quality isn’t always reliable, so it wouldn’t make sense to have it be super strict about it.
But even with that 5-10 times speed allowance sometimes it still rejects some of the merges, and I’m not entirely sure why. I need to do more testing on it to find out if there’s some other special condition that’s causing the maths to not add up in some cases. But that one at least I roughly know the cause of, so it should get fixed in an update soon!
Yep. I’ll have a poke around and find it… Ok, minimum “keeper” duration is 60 seconds and distance 20 metres. So if it’s shorter than either of those, the processing engine will consider it not worthy of being kept as a separate timeline item and will merge it back in. That’ll be the same for both Arc Timeline and Arc Mini though. But yeah, unfortunately there’s no way around that particular rule - the processing engine will always enforce it, undoing some edits. It would be nice to be able to overrule it in some cases though!
Ah, this will actually be a case of both apps being either terminated or suspended. Or possibly the phone failing to provide sensible location data. The phone itself might have decided to just stop delivering new accurate location data for some period of time. That’s most likely to happen after a long period of being stationary, for example when leaving home in the morning.
500-800 metres is much further out than Arc’s accuracy thresholds - even when it’s got especially long sleep cycles it should be easily spotting the movement long before that distance. So yeah, it’s almost certainly a case of the apps either being put in an unworkable state by iOS, or iOS deciding to get sleepy itself when it comes to location data, and only deciding to start doing its job again some distance away from the house.
Yep! If Arc Timeline is the active recorder then the sleep cycle durations will be a bit more sensibly sized, because it uses the statistics of the current place to determine most likely leaving times / leaving probabilities, and do the shortest sleep cycles when you’re most likely to be leaving.
If Arc Recorder ist he active recorder, then it’ll be slightly less intelligent about the sleep cycle durations (for now, until I finish improving that bit), but will still only wait up to a max of 60 seconds I think (and certainly no longer than that).
Though given that Arc Recorder is an incredibly uninteresting app, and the fact that the last app you had in the foreground is the one that will be left as the active recorder (opening the app makes it take over as active recorder), Arc Timeline is most often going to be the active recorder when you’re at home or generally most of the time, so it’ll be doing the better/smarter sleep cycle calculations. Which is why I haven’t worried about rushing to make Arc Recorder as smart in that calculation yet.
It does indeed not want to merge, even with the workaround. It’s not a big issue, though - I’ll just leave it as is and make my peace with it.
I checked and the few cases that did not work for me were above both thresholds. It most often (>95 %) does work as intended. Just sometimes it seems to not want to do the promotion to timeline. In those few cases it is not really an issue for me though, honestly.
Positive update: After a few more days of movement and activity, the apps and processing are still running much smoother and more stable compared to my previous combination of Timeline + Mini. I’m already getting visually used to the blue bar as well. I still miss the lost tapping options, but I’ll adjust to that too.
Hmm. Curious. One case where I see that happen is if it’s a segment that’s adjacent to a visit, and when it gets promoted to timeline the processing engine then decides to steal some of the samples back into the adjacent visit, which then temporarily shrinks it below the “keeper” duration threshold. But I imagine there’s other ways it can happen too.
The timeline processing is basically just a big list of rules it applies, heuristics for making decisions about when to do merges, each of them being rules of thumb we might apply ourselves if tasked with doing that cleanup job. The weirdness tends to come in when different rules are competing, or working together to result in outcomes that don’t seem to make sense. Sometimes it’s obvious why it did something, but sometimes… mysterious
I looked into it a bit more, and this definitely seems to be the case in some of the instances. All the cases where the “tap to promote to timeline” isn’t working as expected involve borderline scenarios with generally short-ish segments. Since these are minor trips / segments, it’s not a big issue if they end up being classified into another location or activity.
If that’s not the case… I might have to send you a debug build with debug logging, so we can do some testing and get some logs to see clearer what’s going on under the hood. Because yeah, it’s pretty weird behaviour!
