after a recent long (~1h30m) drive I saw Arc only recorded the start and the end and then drew a straight line through it. I assume Arc was killed shortly after the start of the trip. Arc Recorder was also running the full trip and not killed. I assumed the 2 would negotiate the difference and fill in the blanks but that never happened. Is there a way I can help here?
Many thanks,
Jan.
Ugh. Yeah sounds like the communication between the two broke down somehow. Which is not a known problem to me at the moment.
There was such a situation a while back, where there was a logic fail in the communication between different versions or the apps (newer version assuming older version was doing things it wasn’t). But that one’s been fixed, so this will be something else.
My hunch is it could be a situation where Arc Recorder had actually been suspended by iOS. Like, the apps are meant to be always “alive” in the background, albeit doing nothing while in standby. But iOS can still decide to fully suspend the apps if it wants to. They’re requesting not to be, and following all the rules to not be suspended, but iOS is the boss and ultimately it does what it wants at the end of the day.
Or another possible scenario is that iOS wasn’t delivering correct/new location data to Arc Recorder, so Recorder thought you hadn’t gone anywhere and was just happily sitting there, oblivious to any moment. That… can happen too 
Though thankfully only very rarely. But yeah, can happen.
Unfortunately both of those situations are out of our control. It’s just iOS doing its thing how it wants, not how we want, for its own private reasons.
But I don’t want to say “that’s just life” and leave it. There’s got to be … something we can do. Hmm. Ugh. I’m drawing a blank. All of the reasons why this might be happening (unless there really is another communication breakdown bug in the apps that I’m not aware of) are reasons that won’t show themselves to us. We simply won’t know that either of the apps … oh wait, well, there’s the “Current Item” widget.
Ok so the Current Item widget will show you little green/red dots for each app, to indicate whether it’s still alive or not. That will reveal the “iOS suspended it” problem, when that happens. If the app has been suspended it’ll no longer be communicating, so the dot will turn red within a couple of minutes. This little thing:
That’s showing that both Arc Timeline and Arc Recorder are alive and well right now. (Well ok, 10 minutes ago. Sigh. iOS hasn’t updated the widget as timely as I’d like it to. Another thing out of our control). But yeah, two green dots = all is well.
Though that doesn’t catch the case of iOS deciding to stop delivering new/correct location data to the app. That one must surely be classed as an iOS bug. But it’s the kind of thing that it’s fruitless to report to Apple, because they’ll require a strict reproduction case, with test code etc. It’s the kind of thing that happens randomly, one day in a month, for no obvious reason. No way they’d take any interest in any report of it.
But at least the widget helps for the first case!
Ok, thanks for the info.
So by suspended you basically mean that the app thinks it’s running but iOS does not grant it any CPU cycles so it might just as well not be running except for using a trivial amount of RAM, correct?
I actually have the widget in a stack on my second screen, but I hardly ever look at it, maybe I’ll check it a bit more now. But if I understand correctly, that wouldn’t prevent this problem, it could just call my attention to it.
I just thought about looking in the Arc Recorder log files, and I found this (my missing drive was 7-mar 15:02-16:27 in the Arc Timeline app)
[15:01:05.502] LocomotionManager.startRecording()
[15:01:05.522] [MISC] tookOverRecording
[15:01:05.527] LocomotionManager.startSleeping()
[15:01:05.527] LocomotionManager.startSleeping()
[15:02:05.533] --1--
[15:03:05.541] --2--
[15:05:05.550] --3--
[15:08:05.562] --4--
[15:11:22.071] [ERROR] [APPGROUP] No AppGroup.currentItemId
[15:11:22.071] [ERROR] [APPGROUP] No AppGroup.currentRecorder
[15:11:23.466] [MISC] concededRecording
[15:11:55.532] [ERROR] [DATABASE] SQLite error 5: database is locked - while executing `BEGIN IMMEDIATE TRANSACTION`
[15:12:55.544] --1--
[15:13:55.555] --2--
[15:15:23.513] LocomotionManager.startRecording()
[15:15:23.530] [MISC] tookOverRecording
[15:15:53.547] [ERROR] [DATABASE] SQLite error 5: database is locked - while executing `BEGIN IMMEDIATE TRANSACTION`
[15:16:23.553] [ERROR] [DATABASE] SQLite error 5: database is locked - while executing `BEGIN IMMEDIATE TRANSACTION`
[15:16:53.561] [ERROR] [DATABASE] SQLite error 5: database is locked - while executing `BEGIN IMMEDIATE TRANSACTION`
...
[16:26:24.594] [ERROR] [DATABASE] SQLite error 5: database is locked - while executing `BEGIN IMMEDIATE TRANSACTION`
[16:26:54.604] [ERROR] [DATABASE] SQLite error 5: database is locked - while executing `BEGIN IMMEDIATE TRANSACTION`
[16:27:54.609] --1--
[16:28:54.620] --2--
[16:29:31.031] LocomotionManager.startSleeping()
[16:30:31.039] --1--
[16:31:31.048] --2--
[16:33:31.060] --3--
[16:36:31.075] --4--
[16:37:03.200] [MISC] concededRecording
[16:37:40.544] LocomotionManager.startRecording()
[16:37:40.548] [MISC] tookOverRecording
[16:37:40.561] LocomotionManager.startSleeping()
[16:37:51.586] [MISC] concededRecording
[16:38:51.605] --1--
[16:39:51.610] --2--
[16:41:51.622] --3--
there is actually 1 big block of 143 identical error messages, 1 every 30 seconds, so I removed most of them (…) and that block covers the exact timespan of the drive!
So to me that seems to indicate that Arc Recorder was indeed running but did not get access to the database (maybe Arc Timeline had it locked when it was killed?).
Note that the log file is actually 7 days long, so that makes it a bit difficult to navigate, maybe adding the date would be an improvement.
The full log file is 6437 lines and 4639 of these are:
[08:17:16.210] [ERROR] [MISC] Error Domain=kCLErrorDomain Code=0 "(null)"
[08:17:46.235] [ERROR] [MISC] Error Domain=kCLErrorDomain Code=0 "(null)"
also always 30 seconds apart
Yep, pretty much.
With the very first iPhones all apps were immediately suspended (frozen in their current state) when they went into the background. That’s how early iPhones managed to get reasonable battery life - nothing was alive in the background, everything was in a frozen state until it returned to foreground.
Eventually Apple allowed some apps to ask for permission to continue running in the background, either continuously or for brief periods of time. Arc is that kind of app - it requests to be left alive in the background continuously.
Though Arc’s own “sleep mode” makes that very low battery life cost, by essentially doing its own suspension. When in sleep mode Arc does nothing for 60 seconds or so, then wakes up for some milliseconds to check if the location has changed, then goes back to sleep again, repeating those sleep cycles until you’ve started moving again. That makes Arc’s background energy cost almost the same as being suspended (depending on how much travel you do while the app is in the background, of course).
But iOS is the boss, and it doesn’t have to respect each app’s requests. If it wants to suspend an app it will, even if the app is playing by all the rules and has requested continuous background time. That… happens. At that point Arc is fucked, to put it bluntly. The only hope is that iOS unsuspends the app before you start moving again.
Yep. Exactly. That’s my own primary use for the widget - just to see those green/red dots, so I know the apps are still alive and there’s not going to be any data gaps. The current item info is sometimes nice to have, but really it’s those dots that I personally care about. Data gaps suck.
Oh dear! That’s… not what I expected in those logs. That’s not suspension, it’s the database locked. Which… is super weird. Hmm.
The database should ideally never get into a locked state like that. That (typically) means that one of the apps is doing a very long running write to the database. While a write is happening no other writes are allowed - SQLite manages them in a serial queue, one at a time. SQLite should only produce that error if a write is going on too long.
But Arc doesn’t actually do any long writes. All writes are small, releasing the database back quickly. So… for it to be locked a long time… I really don’t know why or how that could happen. I have seen it on occasion, and it always self corrects before I can debug it. My suspicion is it’s some internal SQLite housekeeping (updating a large index, flushing the write-ahead queue, or something else I don’t know about).
For it to go on for an hour or so… that’s wild! I wish I had some better idea of why that would happen. Hmm.
Killing the app will actually release the database lock (though it might take a minute or so to happen, which again is a mystery to me). In the rare cases I’ve seen that database locking weirdness I’ve worked around it by swiping both the apps closed.
Aside: In the upcoming Arc Editor app I’ve improved the log viewer considerably, adding search and filtering.
[08:17:16.210] [ERROR] [MISC] Error Domain=kCLErrorDomain Code=0 "(null)"
[08:17:46.235] [ERROR] [MISC] Error Domain=kCLErrorDomain Code=0 "(null)"
For these ones, I finally found out recently that they’re “nolos”, ie no location data. (Core Location unhelpfully reports the errors with no description, so it took me forever to realise). In Arc Editor I’m filtering them out completely, because they’re of no use. They just bloat out the log files.
Happy to be a TestFlight tester for Arc editor 
1 Like
Thanks. And to be clear, that SQLite database is only used by your apps, right?
I recently installed Life360, which does similar things (because my son insists on having an Android phone) but that should not interfere I assume.
I’ll continue blaming it on my ageing iPhone 13 mini with only 4GB RAM.
And indeed, if you need TestFlight testers, let me know!
1 Like
Yep. There’s a secure “App Group” that’s shared by Arc Timeline, Arc Recorder, and also optionally my correlations app, This & That (which uses the database for determining location per day for local weather statistics).
Inside the App Group is a typically very large database file (years of data add up!), that each app accesses, reading and writing to together.
SQLite is isolated to database files rather than being systemwide. So while almost all iOS apps use SQLite under the hood for their database layer, each app is doing it in isolation, on their own database file. So apps can’t interfere with each other in terms of database access.
Now that you mention it, since I upgraded from 13 Pro to 15 Pro last year I don’t recall seeing this database locked thing since! Perhaps either the faster chip or more memory has made the mystery housekeeping process fast enough that it doesn’t cause problems anymore.
I really want to get Arc Editor into public beta soon! It’s already my preferred app, more reliable and faster than old Arc Timeline. It’s just still missing too many things, so while it’s got that “this is much nicer to use” vibe it still doesn’t quite meet the “this is actually a sensible replacement” point. But soon!