I opened Arc today to review yesterday’s data, and noticed a bunch of gray circles in the Calendar view. Sure enough, Arc again reset fully confirmed days of activity to “N unconfirmed” this and that.
E.g. a trip that was confirmed as Car is now unconfirmed, and guessed as Train. A visit previously confirmed as a private place is now unconfirmed and guessed as that place. Weeks of this, going back to last August and even NY 2023.
Now, this is not anything new - this happens regularly, at least once every two weeks, but usually it’s only a few days in the recent past. Today, it was just too much.
For context, I review every previous day and confirm everything in the timeline, daily. I vaguely recall reading here that Arc isn’t supposed to touch data that’s been confirmed, ever. That’s clearly not the case as it does that routinely.
What can I do to stop Arc from undoing my reviews?
It doesn’t. There’s no way that it could unconfirm confirmed items. So what you describe has to be database corruption of some kind.
Though my guess is that it’s actually a problem with the activity type models. If the models update such that they are quite different from their previous state, that can result in items that didn’t require confirmation now requiring confirmation. And potentially also the auto assigned types of the samples could be updated to something different, which would explain what you’re seeing.
Once a sample has had its confirmedType set, there’s nothing in Arc that can undo that (other than some variety of database corruption). So yeah, given that database corruption is very rare, it’s much more likely to be a problem with the activity type models in some way.
Is this happening in a familiar area, where you travel regularly or have travelled many times in the past? Or is it a new area? If it’s a familiar area, has there been any change in your usual routes, modes of transport, etc?
I’m not aware at the moment of any bugs that could be causing the activity type models to be lost, or to update incorrectly. But what you describe does sound like that kind of thing, so I think that’ll be where we should look to debug the problem first. Database corruption should hopefully be very far down the list of possibilities!
Oh, there is one case / bug where Arc can unconfirm a place assignment!
When LocoKit is processing the timeline, if it decides to merge two adjacent visits, or if you split a visit by extracting a segment out of it, which then results in a new automatic merge, the merge process can somehow bug out and fail to copy across the confirmed place assignment in some cases.
I’ve never quite found the cause of that one. The place merging has explicit management of copying across confirmed place assignments, so that one shouldn’t be possible. But clearly there’s a logic fail somewhere in there that I haven’t spotted, which allows for a visit’s confirmed place to get lost in the shuffle.
That one’s definitely on my todos to find and fix! (Although I expect it’ll just disappear by itself, once I rebuild the Places system in LocoKit2 / Arc Timeline Editor).
But for activity type assignments to trip items, yeah, it’s impossible for those confirmations to be lost (without database corruption). When you confirm the type of a trip item, every sample in the item gets its sample.confirmedType value set to whichever type you chose. And the only code that can set that value is the UI code, so it has to come from a user action. Nothing can set it to nil (ie no value set), and only UI code can set it to a non-nil value.
Anyway now I’m repeating myself. Let’s figure out if there’s anything strange going on with your activity type models first. That’s our best bet for solving the mystery at this stage!
The bulk of the days that got affected were from when I was traveling - some trips became unconfirmed, as well as some of the places.
However this also happens to days when I’m at home and going with my daily routine, even when it’s home - gym - supermarket - home routine over and over. It would show walking between those as unconfirmed, or the 23h stay at my house would become unconfirmed.
This month, I’m away from home but staying in one place for a while. Just saw this happen, this morning, to the past ~5 days, again the same thing - trips and places need to be reconfirmed. So, this happens for routine days, as well as for days traveling.
If the models update such that they are quite different from their previous state, that can result in items that didn’t require confirmation now requiring confirmation. And potentially also the auto assigned types of the samples could be updated to something different, which would explain what you’re seeing.
It could be this. I think there’s a very strong argument to be made that if it’s possible for to Arc show a trip or a place in the timeline as not needing confirmation, and then at some point in the future change that, then that’s a straight up bug. As a user, when I review a day, and confirm whatever Arc asks me to, I expect that data to be set in stone. Especially since there’s no difference between “user confirmed” and “Arc thinks no confirmation needed” in the UI. This behavior makes the data unreliable.
Heh. This one’s been debated for years amongst the beta team I’m on the fence - I think it could go either way.
And it is, for the data that you confirmed. The catch is that Arc didn’t ask you to confirm everything, because for some of it it had high enough confidence in its own choices. Then later, when the activity type models (or place models) update, that confidence might become lower. And then the decision changes - then it needs to ask you for confirmation, because its previously confident choice no longer looks confident anymore.
I agree! I think that’s basically the problem. It’s not so much a data problem or technology problem, but a UX problem. The app is doing something that makes sense technically, but from a user / user experience perspective is unintuitive, and often straight up wrong. If you review everything you’re asked to review in a day, then that day could (should?) be considered “all confirmed”.
But that’s where I get stuck. If Arc were to automatically “confirm” any items that it decided didn’t need user confirmation, it would need to know that the user had definitely looked at those items and concluded that the automatic choice was good enough. It can’t guess that from just the timeline view being shown on screen. Could it guess it from the user having gone through the confirmation flow, until all “needs confirm” items have been confirmed? Possibly. But again it’s vague.
One idea that’s come up a few times is a “confirm all” button, or some such, on the timeline view (or more likely in the ellipsis/more menu) that would do that action of “yes, I’ve looked at everything and it’s all good and it should be set in stone”.
But having an extra button for that feels clunky to me. It smells too much of pushing the problem over to the user, when the app should be dealing with it itself.
Another option would be to have Arc treat everything as confirmed if the day is both prior to today (ie yesterday or earlier) and if everything needing confirmation has been confirmed. But again that falls into the trap of “could be quite wrong”, for example if you swipe back through days without really looking at them, and some of them happen to have nothing needing confirmation at that time.
I’m basically still struggling to find the Right Answer (or the Least Worst) answer for that UX problem. None of the current options look particularly good to me.
I mean, I could just put a tick button at the bottom of the timeline view, labelled “all looks good to me”, so that you can’t get to it without at least having scrolled all the way down.
That’s the Least Worst option as I see it, for now. But yeah, I keep waiting until some idea comes along that doesn’t require user intervention like that. Perhaps there’s no such possibility, and I have to accept that an extra button is what it has to be
The reality is that it does not, hasn’t been for years, and won’t any time soon (unless you have a Magical Solution you’re about to implement). In the meantime, this is causing random data loss for users (I’m sure I’m not the only one). It is data loss because once Arc wipes out activity types, and it’s been too long for me to remember what actually happened, that data is now just a best guess and not the actual record of events.
It’s like the problem with Arc recording million segments while stationary due to GPS issues or whatever - in the end, because of the lack of bulk edit option, the user ends up spending inordinate amount of time (hours!) cleaning the timeline. Speaking from personal, excruciating experience I voiced in Dire need for faster edits, which keeps repeating, and there keeps being no option for me to do it faster, due to some vague “there should be a better way” reasoning. But there isn’t!
Not improving a broken UX because of a hypothetical solution that has no timeline is really bad. Like I said, the pain is very real, and the problem keeps repeating on a regular basis.
Please consider this feedback and implement something to make the data safe from random modifications. An explicit button sounds perfect.
I have the same problems with confirmed days turning unconfirmed.
I like the idea of a checkbox on the bottom of timeline that will lock that day. I don’t care how it is called, just lock all changes that I have done manually.
I have an idea for fixing (bulk edit) random bad location data when stationary:
PopUp on location - Begin Stationary location.
PopUp on another stationary which is the same location - Still in the same Stationary location.
Dialog box: Do you want to delete all movement on this location between timestamp1 and timestamp2?
Yes deletes all “random movement” between those two points and merges the same Stationary location.
It happens to me often when I’m at home or at work. Location data is bad and Arc shows spurious jumps to several 100 meters. It takes quite some time to edit and remove bad data like this.
All of the changes you have confirmed manually are locked in, and are never changed by the system - they can only be changed by you.
The issue is that the automatic choices made by the classifiers are not permanent, and may be changed later, if the classifiers think there’s a different best guess once more detailed data is available.
For the bad location data, are you getting much use out of the “Clean up” buttons? Those tend to take care of it for the moderate cases, leaving only the extreme cases (where the bad location data jumped greater distances away).
So I started working on a simple “All Look Correct” / “Confirm All” button at the bottom of the timeline view. I figured it would be super simple to add, and harmless enough, so I could add it quickly in a small update.
Then as I was doing it I realised it would work better as a new “Confirm List” view, showing you a filtered list of only the items in the day that haven’t been confirmed yet. And the existing “x unconfirmed items” button at the top could be reused, to get to this new view.
So that’s what I ended up doing. I’m grouping the “Uncertain Items” at the top. These are the items that that button would previously ask you to confirm - the ones where the classifiers aren’t confident in their auto assignments. Then under that I’m grouping the “Unconfirmed Items” - the ones that the classifiers are confident with, but that you haven’t manually confirmed anyway.
The new feature is finished and ready to go, but unfortunately I can’t ship it yet, due to my dev environment now being iOS 18, and Apple aren’t accepting builds built with the new Xcode yet. But hopefully I’ll be able to send it out within the next few weeks.
Again I’m loosing my mind with Arc adding Stationary segments to Trip.
There is no way for me to remove Stationary segment from Travel time and add it to place time. It looks very bad on the timeline that it took me 18 minutes from garden to home while in fact 9 minutes sounds about right.
Arc keeps adding 2 Stationary minutes from first place and 6 minutes from second place.
I have the same problem on a new location when I go to a holiday.
Please let me decide where stationary time goes, not the ML model.
@Jani, try tapping on the stationary segment and open “Split Segment”. Then split part of it off as car, and leave the rest as stationary. The processing engine will be more likely to leave unchanged a smaller portion of stationary moved into the adjacent visit.
It doesn’t work. When I split, ML stubbornly keps stationary time to trip.
It will only give that time to another place (new or nearby), not the one that I want.
It’s not a problem only with old places like home and work. I had this problem with new places when I was on holiday.
Splitting to Car and Stationary didn’t show any effect, so I split to Cycling. Still it sticks to Car trip.
Hm. That sounds like a bug. If that happens, you could just try again and it should work, as long as you’re assigning the stationary segment to a different place from the one that the processing engine refuses to attach it to.
In those cases typically I will create a new place, something like “Carpark”, to assign the brief stationary segment to. When this kind of problem happens it means there’s a cluster of stationary sample that fall outside of the “gravity well” of the visit, which usually means something like a reception area or parking area or some such. So to work around the processing engine’s strictness, while still maintaining a logical/correct timeline, it’s best to assign it to a new place that makes sense.
My timelines tend to have a lot of Lobby, Reception, Bicycle Parking, etc places.
I agree that it’s not ideal - the processing engine should accept your edits. But currently the processing engine doesn’t know which actions it did itself versus which actions you did. It has no way to distinguish them. So it just blindly goes ahead and “corrects” things it sees as wrong, even if it’s something that you’ve done yourself and want to keep.
I have some ideas for how to improve that in future. And am hoping to experiment with those ideas in the upcoming Arc Editor app. (Which is coming along nicely! I’ve been working on it solely for the past couple of weeks).
I’m on the fence - I think it could go either way.
