Arc stuck in low power mode?

Arc App Support
1

Hi, I drove from UK to France 2 weeks ago, and since then the app has been unreliable. On the journey down, my phone battery was low, and Arc went into low power mode when the phone did the same. The phone died half hour from our destination, but Arc managed to record all the journey up to that point. I mention this only because even since then Arc has been unreliable, and it may be something to do with sampling infrequently, or with low accuracy, as might be the case for a low power mode. Could it be stuck in that mode?

Lots of symptoms, so I will list some examples:

  1. One day an 8km walk was not recorded. Arc was active at the start and end of the walk, and has not been terminated by IOS (no terminations while in France)
  2. At 10am, 3 hours after getting up and moving around house and garden, no data point (not even “stationary” had been recorded.
  3. Records for days in the house include random data points 1-2 km away, usually in the same NW direction. Lots of editing required to tidy up each days records
  4. Two separate 6k walks done on consecutive mornings have been combined as a single walk of 12k lasting 26 hrs, because no stationary data was recorded to separate them
  5. I drove 13k to a nearby town. None of the drive out was recorded, but the app woke up on arrival. And recorded a walk and the drive back accurately in high resolution.
  6. a lot of the recorded events and places show up with purple radius of uncertainty of 1-3km or more, which could explain why movement is not alwaysidentified, and how location can jump to bogus locations.

I have restarted the app, and the phone, but am still having problems.

On a separate subject, is there a detailed explanation of the interface anywhere? I don’t understand all the numbers in the timeline display, or the meaning of the colour coding for example.

Otherwise, I’m enjoying the app, and appreciate the support

Thanks

2

Hi! Sorry for the very late reply. I’ve been having some health issues lately (though thankfully not Covid!) which have sapped away almost all of my productivity :persevere:

Looking at your description… The first guess I’ve got is that you’ve been travelling to places that are quite outside your usual daily routines? Though that wouldn’t explain terminations or data gaps, and would only explain Arc being slightly less accurate at visit start and end times (ie up to a few minutes), and less accurate in detecting activity types for travel (eg car, train, etc).

For the gaps in the data, it’s almost certainly a case of the app being terminated by iOS (even if you don’t see the notification - iOS is sometimes a bit unreliable with those). If you’re on holiday and taking photos, then that would be the most likely explanation/cause of terminations. iOS has a habit of very aggressively killing off almost all background apps when the Camera app is opened, and doubly so when taking photos or recording video.

Unfortunately there’s no good way around that problem. It’s just a fact of life for apps on iOS. The warning notification is supposed to let you know, and should appear within 1-2 hours of the app being terminated (or much sooner, if Arc knows the current place well and knows that you’re likely to leave there soon). But yeah, unfortunately there’s a bit of random unpredictability with those notifications getting delivered.

I would’ve suggested restarting the phone, but you’ve already done that one, so you beat me to it! The other possible cause being that the phone has got itself into a weird state, and needs a full reboot to snap out of it. But yeah, if you’ve already done that then that one’s already taken care of.

I’m hoping to have Arc’s new companion app, Arc Mini, live on the soon. And a big benefit of that app is having both that and the main Arc App running on your phone gives you double protection against data gaps, because if iOS kills off one of the apps, the other app will realise, and take over the job of recording. So it effectively eliminates data gap risk, except for the worst case scenarios, like when iOS just loses its shit and kills off everything altogether (which sadly does happen sometimes :weary:).

Though to get Arc Mini live on the store I have a bit more back and forth to do with the App Store Review team, to satisfy their various approval requests. (Just tedious stuff like making videos demonstrating what the app does, but with my productivity so low at the moment it’s a bit of a struggle. But it’ll get there!)

But yeah, short of having Arc Mini as a fallback, unfortunately when iOS acts nasty like that your only option really is to just keep a close eye on the app, to make sure it’s definitely alive when you head out. And especially so if you’re taking photos - check Arc after using the Camera app, to make sure iOS didn’t kill it off. Especially important when taking photos while travelling.

Arc will get automatically restarted, if iOS does kill it off. But how quickly that will happen is entirely up to iOS’s whims, so it could be a minute, or an hour, or a day. iOS really isn’t kind to apps that need to be running continuously, 24/7 :smirk:

There’s no docs anywhere, but I can answer any questions here, for sure!

Are there any particular numbers in the timeline that don’t make sense to you? Just looking at it now, I see the visit start times and visit durations down the left, then for trip items each one has duration and distance numbers.

If you tap on the visit start time number on the left, then it’ll toggle to showing both visit start and end times (then tapping again will toggle it back to only showing start times).

The colours are semi-unique to each activity type. For example walking is green, cycling sky blue, running orange, etc. The visit items are just coloured the same as the previous trip item, for visual tidiness, and that colour on the visit doesn’t have any special meaning (other than for example a green visit means you walked to that place, because green is the colour for walking).

Cheers :smile:
Matt

3

Hi Matt,

Thanks for the reply. I guess some of the issues might be related to Arc learning about a new location, and some issues have faded (the bogus location data for example). I’m still seeing examples of movement being missed entirely until I am 6-8km from home, and then switching on and working normally (see attached screen shots from yesterday). The straight line section is the trip out, and the return journey shows the actual route. There is no reference to missing data in the “edit segments” display of the trip out, but it is clear that data is missing.

Perhaps IOS is killing Arc while I am at home, but I am not getting a message from the deadman routine you have described elsewhere, so I cannot tell, and it implies Arc is restarting on its own. How can you check if Arc has been killed? (it seems that if you look, it is always alive - like a distortion of Schrodinger’s cat…).

The Arc Lite routine sounds like a great idea to get around IOS shutdowns.

image
image828Ă—1792 86.5 KB

image
image828Ă—1792 172 KB

Thanks for the tips on the interface. I had missed the toggle to marking start and end times, and that helps. I understand the colour coding now.

Still regarding the interface, there were some confusing things when I was trying to tidy up bogus location data, sometimes using the standard “unconfirmed items” process and sometimes identifying points on the map and trying to delete or mark as bogus. The response from Arc varied for different points, and I could not work out an efficient way of doing this. But In the normal way of things, this process is not required, so not a big deal.

Thanks

Nigel

4

Hi Matt,

Ive done some more investigation during a walk this morning. I viewed Arc every few hundred m, and it always showed my location at the correct place, but showed no trail from my starting point. Each time I viewed Arc, the location of the previous stops did not not ( in general) show up as blue dots. At the end of the 6km walk the path is shown as a series if straight lines ( with gaps) apparently corresponding to where I viewed Arc. After a couple of hours Arc is still working on several hundred unconfirmed points, but it is clear that even with editing, the resolution is really poor.

So it is clear that the problem does not relate to IOS killing Arc. Why is it not recording location data, even though it knows the location is changing? I suspect that if i had not repeatedly viewed Arc, no walk data would have been recorded, or just some random points, as I have seen previously.

I’ll attach some screenshots to illustrate. Hope you can get to the bottom of this.

Thanks

image
image828Ă—1792 145 KB

image
image828Ă—1792 140 KB

image
image828Ă—1792 137 KB

image
image828Ă—1792 172 KB

image
image828Ă—1792 158 KB

image
image828Ă—1792 106 KB

5

Yeah the confirm/correct flow has some annoying quirks, that I need to find time to smooth out. It can be inconsistent in what it shows next, and will sometimes/often eject you back to the timeline view while you’re trying to tidy things up. I hope to get that smoothed out more over time.

It will still be due to iOS killing the app. The warning notifications are not immediate (they default to 2 hours if Arc didn’t have enough information to predict a more sensible shorter/longer wait period).

The reason I say it’s still due to iOS killing the app is that as long as Arc is alive, it will always be recording new samples, every 30 seconds at minimum (and up to as frequent as every 2 seconds while walking/running/cycling). So as long as Arc is alive, there won’t be gaps in the data, and you won’t get straight lines between points, like you’re seeing in your data.

As to why iOS is killing the app so frequently… I wish I knew! There’s no easy way for you to find out on your own phone, other than turning on some phone debugging settings and sifting through potentially hundreds of cryptic system log files.

Though the most typical causes are memory consumption (not by Arc but by other apps demanding it, eg the Camera app, which results in Arc getting forced out), and CPU use. When Arc is recording it doesn’t use much CPU at all - it’s only when the phone is plugged in to power and Arc is in sleep mode (eg you’re at home, not going anywhere) that Arc uses a lot of CPU, to do daily housekeeping tasks. And that is always done with iOS’s permission, after requesting a background processing task slot and indicating that it requires power.

I’m trying to think what advice I can give… but not coming up with anything useful unfortunately. This kind of situation really is out of your or my control. Really the only viable path forward is to keep an eye on it, and hope that iOS calms down soon and stops being such a dick. Thankfully that typically does happen - these weird reliability failure incidents tend to be short lived, and everything mysteriously comes right on its own.

6

Matt,

Thanks for the reply. It seems I was waking up Arc everytime I looked at it then.

Anyway I had the same problem this morning, with no data recorded after 2km, so I restarted the phone again, and everything started working normally. After processing the data the second half of the walk was recorded perfectly, even reporting a 2 min data gap as the phone was restarting!

So the problem is solved in classic tech support style - switch it off and on again - twice! I’ll know what to do if it happens again.

Thanks again for your help, and the detailed replies. I have an idea of the complexity of the app from the other replies on the forum, and can see the challenge.

1 Like
7

Correction, it was a soft reset that fixed it

8

Yep. The clue here is whether you see the Arc launch logo screen (plain white screen with the Arc logo in the middle) briefly appear. If you see that, it means it’s a fresh app launch. If there’s a brief moment of black screen or white screen before the app appears, but no logo, then that just means the app was in a “headless” state while in the background, but was still alive.

Aside: The “headless” state is where Arc discards all of its UI in the background, so that it’s running in the most slimmed down “chopper” state, with the smallest possible memory footprint. In that state Arc can use less than 50MB of memory, which is Apple’s recommended threshold for best avoiding getting killed in the background when other memory hungry apps need memory (eg the Camera app).

When you see that plain black/white screen briefly on opening, that’s Arc going from headless to “growing a head”, ie building a UI to show you. That UI will then be discarded again, some minutes after the app goes in the background again, to keep memory use under that 50MB threshold and best hide from iOS’s angry eye.

But if you see the launch logo screen, that definitely means it was a fresh launch. That’s the wince moment for me, if I see that during daily testing.

It seems silly that this is still the right answer sometimes on iPhones! You’d think computer tech would be past that. But yeah, it still does seem to be the most effective way of snapping the phone out of whatever mess it’s got itself in :smirk: