Ah I just realised “scheduled” isn’t added to the log files, because it’s done every time the app goes into background. It’d just be too much log file noise.
In the Background Tasks section of the Settings tab you should see it saying the current status of the tasks - whether they’re overdue, last completed, etc. Though I think there’s a missing detail for the case of them never having completed for the first time.
@o1x Just to double check: You don’t have Background App Refresh disabled on your phone do you? Or the phone often in Low Power Mode? Both of those will stop scheduled tasks from running.
If those are both non-issues, then unfortunately it really just comes down to iOS not being friendly, and not deciding to run the tasks yet!
@matt I found some SQL errors in the logs. Would those help or you’re aware?
@agastya I’m aware of those! Well, depends what they are. But probably they’re something like “cannot set previousItemId to a deleted item”?
If it’s that one, then it’s all good - I’ve fixed it in the next build, and it was harmless enough anyway (just annoying to see in the logs).
But if it’s something else, then yeah I’m curious!
Oh wait there’s also “cannot delete TimelineItem with existing samples”. That’s also harmless but annoying. I’m not sure if I’ve got rid of that one in the next build or not…
Yes there were a few of the first one you mentioned. Then something similar and a few others:
SQLite error 19: Cannot set nextItemId to a deleted item while executing ‘UPDATE “timelineltemBase” SET “previousItemId”=? WHERE “id”=?’
SQLite error 19: CHECK constraint failed: (“uncertainActivityType” = 0) OR (“confirmedActivityType” IS NULL) - while executing ‘UPDATE “timelineItemTrip” SET “confirmedActivityType”=? WHERE “itemId”=?’
SQLite error 9: interrupted - while executing 'SELECT “timelineItemBase”., “timelineItemTrip”., “visit” .*, “place” * FROM “timelineItemBase” LEFT JOIN “timelineltemTrip” ON “timelineltemTrip” “itemId” = “timelineItemBase” “id” LEFT JOIN “timelineltemVisit” “visit” ON “visit” “itemId” = “timelineItemBase” “id” LEFT JOIN “place” ON “place”.“id” = “visit” “placeId” WHERE (“timelineItemBase” “deleted” = ?) AND (“timelineItemBase” “disabled” = ?) AND (“timelineItemBase” “endDate” > ?) AND (“timelineItemBase” “startDate” < ?) ORDER BY “timelineItemBase”. “endDate” DESC
Oh the “CHECK constraint failed” is a bit naughty. It won’t be harmful, but it’s telling me I did something silly somewhere and missed an edge case. Hmm.
The “interrupted” one, was that just before/after a CancellationError()? Those are supposed to all be caught and dealt with. If they slip through to the log file it means I haven’t properly handled a case.
Entirely harmless, but it’s something that’s meant to be very deliberate, ie whether a database action is allowed to be automatically cancelled or not. Like, if it’s just reading in data for display in the UI, then usually that’s fine to be cancelled (eg you tapped through to a different view before it finished, so there’s no need for that data anymore). And in those cases I’m meant to be catching the CancellationError() and saying “meh, that’s fine; ignore it”. If it gets to the log file it means I haven’t done that!
Anyway, I’m rambling 
Hopefully I’ll see that one myself soon, and realise where it is in the app and clean it up.
Screenshot of the interrupted error.
I figured the errors weren’t too much of a concern and you’d probably find them eventually on your own.
Oh weird, no CancellationError() before or after. I wonder what that’s about. Still looks harmless though - it’s just a query that’s loading data presumably for UI.
But yeah, all these SQL errors going to the log files are there to be annoying enough to push me to tidy up something somewhere! There’ll hopefully be less of them in the next build (coming maybe tomorrow), but still some left to go.
You might also see some HealthKit permission ones too, on occasion. Those are also harmless, but especially annoying to me because they make no sense. (They’re telling me that something tried to access HealthKit in the background, which is forbidden, but every single bit of code that touches HealthKit already has a foreground check before it! Sigh)
A few days after installation of the App, I still have the same number of tasks in the queue (1.677 pendig). The number had changed +/- 2 tasks meantime, but it remaind on that level.
Seems for me, that the tasks DO run, but the process quits, when trying to update the place!
All logs show „places UPDATING: Zuhause“ among their last log entries. When I restart the app, a new log is created.
I just experienced two back-to-back crashes of the Arc Editor. I heard that you use sentry that you might have gotten the report already? Otherwise from the analytics section of Settings it says there’s a SIGTRAP:
"exception" : {"codes":"0x0000000000000001, 0x00000001008bbcf0","rawCodes":[1,4304125168],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"},
"termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace\/BPT trap: 5","byProc":"exc handler","byPid":447},
"os_fault" : {"process":"Arc Timeline Editor"},
Let me know if you need any more information. I was just switching between days in the timeline view and then opening the individual segments view to do a cleanup.
@Helge Try tapping the filter button (circle with lines in it) and selecting “tasks”.
If you see “expired” then that means iOS decided to stop the task before Arc had finished doing all of it. If you see “unfinished” then it means Arc stopped the task before it finished.
Oh, the app is actually terminating?! Hmm. That’s not good then. I wonder if it’s loading too much data into memory, then iOS is terminating the app itself instead of just the task.
Ok I’ll add a todo to do some memory use profiling on the Place updates. Maybe it’s loading in too much data at once!
Thanks for the heads up! I think I might’ve found it in Sentry. There’s a couple of new crashes that’ve appeared since yesterday. Will see how I get on today with hunting them down.
Discussion continues in the new thread for the second public beta: Arc Editor public beta 2
Matt,
I found this error in the logs of beta 1 which I assume might still be there. Once I switched phones without an iCloud backup and then had to do a restore. Maybe it is from that. Perhaps it is not significant yet I’m not sure if maybe anything might be missing somewhere or if there might be some future way to correct such.
@agastya Ah that “key not found in table” sounds worse than it is, thankfully. Though it does annoy me, in the sense that I’m not sure why it happens. But it is thankfully just a harmless side effect of something of low consequence.
I think, from memory, it’s something in the ActivityType model updating. When the system is collecting up samples for the model training, sometimes it thinks there’s a sample that … isn’t. Harmless, but super weird.
Ah yeah in your screenshot the line just before is a model update. Though I would’ve expected the error to come before the update completes. Hmm.
Anyway yeah, it’s another minor “eh?” thing for me, rather than anything to worry about. I’ll keep chipping away at these over time. There’s only a small handful of them still present, and all of them (that I’ve seen) are non-issues. Just signs that I’ve got a slightly sloppy bit of code somewhere, that should be a bit more tidy.
When will these data updated? especially the places number. that is way less than the real places I visit in a month.
It should be updated when the Places get updated, during the scheduled background task. But I think what’s happening is the reverse geocode service that it uses (Apple Maps server side API) is rate limiting the requests, so only a handful of them get done. Which means the Places get marked as updated, but the reverse geocode for them hasn’t happened.
You can work around it by going into the edit view for various Visits in areas where you can tell the report is missing. When the place results list is loaded any places in the list that are missing reverse geocode data will have that filled in (as long as the Apple Maps API doesn’t rate limit again).
So what I’ve been doing for myself is noticing when the report is missing a country or city, or its showing a number of days that I know is too low, then going to the timeline view for those days and tapping into the edit view for one or two visits. That’s enough to get that information available to the report.
Eventually there’ll have to be a better system for working around those rate limits. But yeah, for now in these early betas, if the rate limits hit, the reverse geocodes just get forgotten until you open a relevant edit view.
Oh this is only for Places that were imported from the old LocoKit database. For new Places added after Arc Editor was installed, those should all have reverse geocode data done immediately. They’re not added fast enough to hit the rate limits most of the time.
So it’s just that massive chunk of hundreds or thousands of imported Places that trigger the rate limiting.
Do you mean go to the day view? Or do you mean to go to each visit that is not counted inside the places? I tried to go to the day view but seems not work.
And yes, all imported from old data so they almost all missed
