I switched to a new iPhone not using the Apple backup and restore, but the Arc iCloud Drive Backup is on so I thought that would be fine, but it is not.
I moved the Previous Backups folder to Import folder but after importing successfully, there is still nothing in the timeline. All my data is gone.
After restarting the app, it shows up one week of data with only “data gap”, no data prior to Sept 15.
Samples pending backup is 490k, so I believe there is data in the Arc database but not showing in the timeline?
Hmm. This sounds like an edge case bug that got fixed a few releases back. Though if you’re on a new phone you surely must have the latest Arc version installed. Curious.
Just to double check, you definitely see all the desired week files in the LocomotionSamples folder / Sample Files section of the File Importer, yeah?
After a long wait the data is finally showing up. But now I have a problem that if my home have bad GPS connection and I don’t go outside frequently, then after a while, Arc will mistakenly mark almost all activity as “stationary”.
I’m not sure what you mean by that one. If you’re not going outside, isn’t stationary the correct classification?
Or do you mean data recorded when you are outside and moving around?
If that’s the case, it might be that the activity type models are still rebuilding. Though that should self resolve within only one or two days, for your current location. It rebuilds the models for your current location first, so that new data is getting correctly classified first. The models for other areas will get rebuilt afterwards, and getting through that list can take a few more days sometimes, depending on how friendly iOS is being in terms of allowing Arc to run its housekeeping tasks in the background.
The problem seems to be the iPhone 13 mini I previously using, on that device when I am at home (that specific location), the GPS location drifts often and have an offset, as I mark those as stationary, some of the walking activities (that I am outside and walking) are also categories to stationary.
The location becomes somewhat more accurate when I am at home after I switched to 15 Pro, but the old data is still there, also currently there is an offset of my home location’s yellow circle because of the drift. I just want to confirm if there is a solution, or will it correct overtime as I use my 15 Pro. Also, will the yellow circle of that location eventually become smaller or it will only become larger?
I just want to confirm if there is a solution, or will it correct overtime as I use my 15 Pro.
That well definitely self correct over time! And it should happen fairly quickly. I would say in a matter of days, or weeks at most.
The activity type models tend to learn very quickly from new data, as long as that data is confirmed / corrected. (It can’t learn from anything that it isn’t explicitly told about).
That should also become smaller and more accurate.
You will also notice this over time with larger buildings, if you change where you spend time in them. For example if you work in one specific corner of a large warehouse the Place’s orange circle will be around that corner, but if you then move to another department in the warehouse and work in an opposite corner, the orange circle will gravitate to that new corner over a period of days or weeks, with the intermediate period likely encompassing both corners.
Basically the Place models represent the data from the past … however many visits (I don’t remember exact numbers - it’s a lot of visits, but not so much that it takes too long to change if your behaviours or the location data changes).
Thanks for answering, I have another question. I still have somewhat bad GPS signal at my home which causes “drifting” sometimes. I was able to mark those as bogus in Arc, but they eventually count as a separate “visits” to my home location, like Home - Bogus - Home. I found that those “visits” will not merge unless I change the bogus “transportation” to type stationary. But will doing this cause any issues like counting those bad samples as stationary, causing not only inaccuracy of my home location but also mis-categorize other activities as “stationary”? Thank you!
Ah, this is one of the areas where I want Arc’s processing to more intelligently handle things itself. It doesn’t quite do what we intuitively expect or want yet!
Ok, so the reason why it won’t merge some of those bogus items is because it’ll only merge over a bogus item if all of the samples inside of it are confirmed as bogus.
So for example if the drifting item has segments “walking → bogus → stationary”, it’ll treat it as still a potentially valid timeline item, and not immediately consider it appropriate to merge over it. But if you change every segment inside it (from the “Individual Segments” view) to bogus then it’ll consider the entire item bogus and definitely merge over the top of it.
There’s also another subtle distinction that matters here - and one that I want to make go away soon. The activity types classifier might automatically mark some samples as bogus, based on what it’s learnt. But auto detecting bogus is incredibly difficult and the classifiers tend to almost never get it quite right. So I’ve got the merge rules treating automatic bogus differently from confirmed bogus. Meaning that even if the classifier thinks the whole thing was bogus, it won’t get merged in automatically until you go in and confirm that it’s bogus. Annoying!
I’m probably going to change that soon, and have it treat auto bogus the same as confirmed bogus. Because even though it doesn’t do a good job of detecting bogus, it’s even more annoying that you have to go and do the job again yourself.
You can tell the difference between “auto bogus” and “confirmed bogus” on the Individual Segments view by the colour. If you’ve confirmed the segment bogus it will appear as red text in the list.
The general rule of thumb I use is roughly 100 metres: If the segment is within about 100 metres of the real location, I’ll mark it stationary. If it’s more than 100 metres away, I’ll mark it as bogus.
Though I tend to adjust that threshold based on “feels”. For some places it feels like a tighter radius for what defines bogus versus sensible makes sense, so I’ll mark some segments bogus even if they’re only 50 metres away, or some such. Just depends what feels right from the look of the map - instinct rather than maths.
Oh, you can also tap on the stationary segments on the Individual Segments view and assign them to the Home place. Which can sometimes help to prune off some valid looking stationary bits and add them to the Home visit, instead of making them all as bogus.
But yeah, all of this stuff is still pretty awkward. It needs to be better. I’ll actually be working on it again this week, so maybe I’ll get some of it working more intuitively soon.
Thanks for replying. I believe everything looks correct for now.
Is that possible to add an option to exit sleeping mode (and start recording mode) immediately in the Arc Recorder app. The reason is that I have bad GPS in my home and somehow it results the sleeping mode not existing until I was like 30-50 meters away from my home.
Also I have all three apps including mini installed, and I see they both consuming battery, should I turn off the location permissions for Mini so it won’t consume battery?
You can trigger exit of sleep mode by going into the current item’s Individual Segments view and splitting off the most recent samples as walking or car or some such, then tapping them again to split them out as a separate timeline item.
Though in practice there’s not really any point in doing it, unless you’re wanting to record a brief walk that would usually never get recorded. If you’re genuinely leaving the house and will be travelling far enough for recording mode to restart on its own, then doing any tricks to force it won’t achieve much difference in results.
The reason for that is that even in sleep mode Arc is still recording. It records new samples every 6 to 60 seconds while in sleep mode. So even if it hasn’t exited sleep mode yet, it’s still recording location data and saving it to the timeline. Then when the timeline items are next processed, those recorded samples will be pulled out of the home visit and added to the start of the car/walking/etc item, so that it links up properly in location and time.
When Arc knows that you’re very likely to be leaving your current location, it will be using the shorted sleep cycles, eg a new sample recorded about every 6 seconds. It does that in the expectation that it’s probably going to restart recording soon anyway, so it’s collecting higher frequency data with that expectation in mind.
So I guess you could call that “light sleep”. Recording more frequent data, and ready to use that for the next timeline item once it’s certain that it should definitely wake from sleep.
Personally I’d just uninstall Mini, and only leave Arc Timeline and Arc Recorder installed. No one ever really liked Arc Mini’s UI - it was just a clunky, minimalist version of Arc Timeline. And now that there’s Arc Recorder to serve that fallback job of making sure there’s no data gaps, there’s not really any point in keeping Arc Mini around. Two apps is enough!
Is there a way to check the system debug info without mini?
Also I believe mini’s timeline view is kind of more accurate representation of the timeline data in the database. Sometimes the main Arc app doesn’t show timeline items correctly and I have to kill it…
Ah good point. Not right now, no. I’ll make a note to add some of the debug views to Arc Recorder.
Also a fair point. Although both Arc Timeline and Arc Mini are relying on the aggressive timeline data caching (which is what causes the visible timeline data to sometimes be out of date), when you switch between them you’ll often get fresh data loaded during the switch.
As a general rule of thumb, I’d advise against swiping Arc closed. Although I can’t say for certain, my hunch is that it can send the wrong message to iOS - that you want that app terminated more often. I don’t have any good evidence that it makes a difference to whether iOS treats the app well or not, whether iOS will then terminate the app itself more often or not. But I also don’t trust iOS at all on that measure, so I’m wary of swiping the app closed unless absolutely necessary.
That could be entirely superstition though! Apple intentionally don’t document how those internal app behaviour scoring processes work. So I could be fussing over nothing there 