Hi,
some time ago (I don’t check Arc that frequently so I can’t tell exactly when), both Arc and Arc Mini started showing that they are “thinking” never actually finishing, and Arc Mini hangs almost immediately and after about 30 seconds, it crashes.
Do you have any idea on how to fix this? The apps have become unusable.
Thanks and best regards
Lino
While I was troubleshooting this right now, it stopped saying “thinking” for a little (now it’s back) but if I go two days back on Arc Mini, there is a “Car” segment of 1 day, 8 hours (that of course never happened, because I don’t usually travel by car for 32 hours straight), the app then hangs and then crashes.
Sometimes, when I open Arc, it starts with “database updating” but then it clearly doesn’t finish the whole thing and then goes back to normal, if I cycle the app it goes back to database updating. But it doesn’t do it always.
Hi @LinowPeesto! Sorry for the slow reply. I’ve been on vacation. (Still am! But the ski resort is closed today due to wind, so I guess it’s a work day now).
It sounds like possibly your database file is corrupted somehow. What you’re describing is one of those “should be impossible” things. The database migrations can’t happen more than once (that’s something enforced by the database layer itself). So for it to repeat again after “completion” means … yeah, likely corruption.
Though definitely make sure that you’re seeing the migration view disappear on its own and the timeline view appear. If the app crashes before the migration view disappears, then it means it isn’t completing the migration, and will likely restart it again on next launch. Also swiping the app closed during migration will … do harm.
Anyway, if it doesn’t come right on its own, then unfortunately you’ll likely have to do a restore from backup. To do that, make sure that Arc’s optional iCloud Drive backups are turned on in Arc’s Settings view, and that they show as having recently completed.
If there is a recently completed backup, then you can delete the apps (need to delete both of them to fully remove the shared database / app container from the phone), then reinstall Arc and start the process of restoring from backup. Though definitely don’t delete the apps until you see that a full backup has recently completed!
No problem man, enjoy your vacation and don’t work if it’s windy, read a book or something! 
you deserve your breaks.
Well that’s just my luck, I guess. I have iMazing so I can copy down the database if you want, and if you need help understanding the situation… just tell me the queries (here or via PMs) and we can navigate the bug.
I’ll see if I have the courage to do the backup restore, maybe you still remember last time I had to reimport everything it was very painful, and I’m quite scared iCloud will decide to nuke the backup if I delete the app. I have a rather large history file so I’m not exactly looking forward to this.
By the way the app still works if I open it and then leave it in the background, so I know it’s still recording. It’s the “thinking” that is clearly not working anymore.
Unfortunately if it’s a corrupt database file there’ll be no fixing it 
One of those “just bad luck” things. Once corrupt, there’s no coming back from it. It used to happen a lot more often with SQLite databases, years back. I remember losing my entire Moves app history to database corruption back in those days.
Definitely make a copy of the “Backups” folder in the Arc App folder on iCloud Drive. That way you can feel confident that even if iOS does anything weird along the way, you’ll still have a copy of the backups somewhere else.
Yeah it’s never fun 
Though usually it is a smooth enough process. It’s just that when the restore goes weird it’s a lot of manual work to get it done!
That is weird. Is it still doing the “migrating database” thing too?
If the database was corrupt the app wouldn’t be able to write in it at all, right? But the app still works just fine. I just can’t navigate without it crashing.
Yes it’s still doing the “database updating” when I open the app after I cycle it.
Arc Mini crashes if I keep it in the foreground. This is the status on the widget. By the way, I’m at home not moving at all and I’ve been here for the past three hours of which the phone was on a sofa for at least two of them, so the “car” is not very accurate at all.
oh now it changed to this! what does that exclamation mark mean?
btw I’m not proposing analyzing the database for fixing it, I’m know I’m fucked at this point 
I’m talking about understanding the problem and trying to see what caused it.
Yeah you’d think, but there’s actually two databases, so it’s possible one is corrupt and the other not. The main one contains all the recorded samples and timeline items, and that’s the big one. The other database contains place information, as well as your activity type models used for classifying samples, and some other auxiliary bits and pieces.
For it to continue recording in the background, it might be that the main database isn’t corrupt while the other is. Although I guess it is also possible that the main database could be corrupt in a way that only causes crashes when some parts of it are accessed that aren’t required for core recording functionality. Like there might be a corrupt index that’s only used by some parts of the UI.
Though that’s all pretty vague speculation. Really hard to know what’s going on, even with direct access to the database! The fact that it’s still doing the “database migrating” thing on launch is what’s making me feel most certain that at least some part of it is corrupt. Each defined database migration is a one-and-done thing, and can’t be repeated. So the fact that it keeps trying to repeat that on launch is … yeah, hard to know exactly what that means, but it doesn’t mean anything good
The exclamation mark means that the widget can’t find a “current item”, so it doesn’t know what title to show. Although that can actually happen during normal operation too - there’s some intermittent communication failure with the widget that makes that happen occasionally. (It annoys the hell out of me! Wish I could fix it).
The more telling thing in the widgets is this little red and green diamonds and squares at the bottom right. The first one is for Arc App and the second is for Arc Mini. Green means the app is alive and red means dead/terminated. Circle means that app is the current active recorder, square means that app is in standby, and diamond means dead. (So red colour and diamond shape both mean the same thing - dead).
In that screenshot it means Arc App is dead/terminated, and Arc Mini is doing the recording. I guess one of those widgets is for Arc and the other Mini? Looks like when the widgets were updated they had slightly different information, with one of them thinking Mini was the active recorder (green circle) and the other thinking there’s no active recorder at all (red diamond for Arc, and green square for Mini, meaning that Mini is believed to be in standby).
Yeah, I’d love to know too. If it weren’t for the “database migrating” thing, I’d think that possibly it’s a “mega visit” problem, where somehow the timeline data had become corrupted rather than the database itself. But with the “database migrating” on every launch, it seems to me it must be a step worse, with one or both of the databases corrupt in some way.
Though it it were “only” a mega visit problem, it still wouldn’t be recoverable without a restore from backup. Well unless possibly you take a long trip - long enough to break out of the mega visit’s radius. But given the database migration thing, I don’t think there’s any hope to be held onto there.
I think the thing to do will be to do a fresh install, then manual week by week restore from backup using the File Importer view, going from newest week to oldest, checking the timeline after each, to make sure corrupt data hasn’t been imported. And if it has, attempt to clean it up before the problem compounds.
Unfortunately if the database becomes corrupt and/or the timeline data becomes corrupt, that still ends up being reflected in the backups. So if there’s a mess in the data in the app, it’ll be a mess in the backups too. Hence the need for week by week restore until the problem data is found. (Assuming there is problem data, which isn’t certain at this stage - it could be entirely caused by database file corruption. Really hard to know).
Bit of a nightmare! My main takeaway personally is: I wish I’d prioritised breaking up the main database file into smaller “sharded” databases, because it’s just way too big these days. Smaller database files (perhaps one per year, or some such) would be more manageable, and also more resilient to database file corruption. But also more complex for the app to manage, so it’s not a project I want to take on lightly. It’d be a major reworking of the entire guts of the system. Though one that I suspect eventually will be necessary. The database files are just plain too big.
Oh, one thought: Does your phone ever fill up? Like, is it running out of space? My hunch is that that’s one of the ways that database file corruption can happen. If the phone runs out of space then the database file can’t be enlarged with new data, and shit goes bad.
Another possibility is the phone running out of battery and suddenly turning off. Although SQLite uses a “journaling” system specifically designed to ensure sudden interruptions like that can’t corrupt the database. (File systems these days use similar journaling systems, to avoid file system corruption on sudden power off etc).
But given that database file corruption does still occasionally happen, and can’t always be explained by running out of storage space, I still have that hunch that sudden power loss could be a potential cause.
No, never filled up. I always had a healthy amount of space. Neither it ran out of battery often.
So… even if I recover from backup at this point I’m still probably screwed, and I would have to import manually again until I find the wrong data, then basically remove the wrong data from the data set and do a complete import?
That’s… huh, that’s not exactly very appealing. Even one manual import last time was a pain, now I need to do many.
Gwah. I’ll see what I can do. Not looking forward to it 
Yeah pretty much
Although I’d still personally try an automatic restore first, just to see. It might be that there’s no major messed up timeline data, and the problem is purely database file corruption, so an automatic full restore might succeed without recreating any mess.
But if that does end up recreating some sort of timeline mess that can’t be cleaned up, then yeah it’d have to be week by week. Although once you find the problem week and clean up that data, importing the other weeks can be done all at once, with the “Import All” button. It should only be the process of finding the week with the messed up data that’s slow.
In my hundreds of tests of the File Importer, I’ve typically avoided the “Import All” button (other than to make sure it does what it’s supposed to) and instead tapped on several weeks at once, queuing up a month or so at once. Then waited for those weeks to finish importing, which typically doesn’t take long, then check the timeline view to make sure it’s all clean. Then repeat.
That way, during my testing, I was able to do full restores via the File Importer fairly quickly, while still avoiding the “Import All” button (which is basically just what the auto restore system does - it just does the equivalent of tapping Import All).
I started checking the data to see if there’s anything obviously broken in the past month and man, I’ve got to tell you, the app is not looking good. I see you’ve been told this already many times about all the problems, but I’ve got them all:
At this point, me, personally, I would trade all of this machine learning automated categorization with rule based categorizations immediately. It’s just not worth it. I know you already thought about it and you have your ideas and you probably know how bad it can get doing it other ways, but +1 for yeeting all of this to the bin. It’s a complete disaster.
The app is not reliable in recording all days anymore, the stationary locations are not reliable anymore, the historic data is not reliable anymore, the editing tools are not usable anymore and if you have an older phone the UI is slow to the point of just not being feasible to edit more than a few items without frustration. And this is without even considering the situation why I’ve opened this thread in the beginning, which is, the apps corrupted the DB somehow and I have to waste a lot of time hoping to fix this.
I’m so grateful for this tool and it truly is the best one of its class, but man, this is not going in the right direction. If there was an alternative with import/export of data I would absolutely switch tomorrow. I don’t really know what to do of all of this right now, it’s just too many problems, and I’m also paying more than any other app I have on my phone to have them.
During recover from backup, if the “moves_export” folder is still in the arc folder, it fucks up the restore process. I’ve put it there in 2019 and it bit me in the ass 5 years later
Putting the stuff in the import folder manually is quite a pain as it needs to sync with iCloud first and… man everything is so slow. And the importer crashes quite easily.
I really did not look forward to this.
The automatic restore also gets stuck importing at the first two items. Sigh.
@matt the situation is very dire. I can’t basically import anything from the backup. It’s so slow it’s impossible do to anything. Every item takes about 5 minutes, meaning the whole 2500 items will take about 150-200 hours, all of them have to be with the app in foreground (with the screen on!) otherwise it stops working.
And after that, I have to restart about a third of the imports because they fail (exclamation mark with the counter clockwise arrow around it). So total time will be more something like… 300 hours total.
It’s absolutely impossible for me to recover anything at this point. I’m stuck with a broken database and the app that keeps on dying or no database at all and losing access to all of my historic data.
To say I’m not happy is a bit of an understatement. To have 10 years of data in this situation is just… not ok. This is the second time I go through this byzantine backup recovery system and somehow now it’s even worse from the absolute ordeal it was the first time.
Please, find a solution to this. At the very least, in the next version unlock the 2 elements at a time limit and restart items that failed automatically. I can’t waste more time and mental effort into this anymore. Thanks.
The trick for that is to open Files app and long press the folder and select “Download Now”. Files app gets to do bulk iCloud Drive syncs more efficiently.
Once Files app has done that, the manual restoring in Arc’s File Importer will be significantly faster, because it doesn’t have to queue up an iCloud Drive download for each file first.
Anyway, from the sounds of it you’ve already deleted Arc and Mini and started the restore from backup? If so, the classifier accuracy problems you’re seeing are expected and temporary. The backups don’t contain your activity type models (the things that the activity type classifiers use), so those need to be rebuilt, which will happen automatically overnight.
I wouldn’t bother trying to do any significant cleanup of old data during the restore from backup. Just make sure you’ve got the data restored, then look at cleanup after that. It’ll be much quicker that way, and Arc will be able to update its activity type models with all available data, so it won’t make weird mistakes and waste your time asking for confirmation of stuff that shouldn’t need it.
I ended up moving the “previous backup” so I didn’t have to redownload everything, but staggering the locomotion samples by year is still a pain because I have to move out stuff around and it’s very slow.
Everything is downloaded and yet it’s extremely slow to import. About 10 times slower than it was last time. Once a week has gone through with the import, if I try to import it again it goes super fast. If I had to guess, the problem is with the timeline items, I have 180.000 of them now and it’s taking a toll with the filesystem to find them and import them. But I’m no programmer so you know best.
When I talked about the data quality situation, it was before I started the import. I went back to check if there was something weird, a day that makes the app crash or whatever, and while on the way there I wanted to clean up a little bit and I found out this absolute mess. Then I started this whole ordeal.
Yeah the second time through it’ll just be checking to see if that data is already there or not, and skipping over it if it is. So second time through it shouldn’t have any work to do.
If there’s 180k timeline items in the backup, that’s definitely a problem! Or at least a symptom of one.
Let’s say you go to 4 places each day of the year, that’d mean there’d be 7 timeline items for each day (4 places, with 3 trips between). So 7 * 365 days * 6 years = 15k timeline items. Having 180k timeline item files is … yeah, I don’t know what that means, but it’s not good, and I imagine would surely make the file system unhappy and things in the importer run slow.
It’s good to make sure you do any requested confirmations/corrections on the day, or soon after, otherwise larger messes can grow. The activity type and place models don’t have any inherent intelligence - they depend entirely on what you teach them. So if there’s a lot of timeline data the models have asked for confirmation on but they haven’t received it, they’ll inevitably be dumber and more prone to making silly mistakes.
Yeah but… Now?
The import still goes even if the app is not in the foreground, but significantly slower. So slow I thought it was completely stuck. At this rate it’s going to take more than two months, even three, to go through the backups. All the while, the app uses quite a bit of energy.
What are your suggestions to fix this?
Unfortunately I don’t have any good ideas
It’s possible that once the database became corrupt, the processing engine started creating a new timeline item for every new sample, which would explain the endless “thinking” and also the massive number of timeline item files in the backup. I think that massive number is probably why the importing is going so painfully slow. I think your hunch is right that the file system is suffering under that weight.
But there’s no way to identify and remove the unnecessary timeline item files, so we’re stuck. You could try renaming the TimelineItem folder so that the importer can’t see them, which should speed up the import. It would import the samples unattached to timeline items, and the timeline processing engine would then have to work through them all and attempt to recreate the timeline after import. Which would mean having to do a potentially massive amount of manual cleanup after the import is all done.
But I really don’t think it’d be worth it - it’d just shunt the problem from one place to another, and potentially mean you never get the old data back to as clean as you previously had it. It’s something I might consider trying myself as an experiment on a separate test phone. (I do know it’d “succeed” because plenty of tests like that were done during development, but I don’t know that I ever did it with an entire database of years of data). It’s certainly not something I’d ever want to deal with on my personal database on my main phone. I’d give it a pretty strong “no” vote.
I think given the situation, what I would possibly do personally is treat it as a long term project, as I have done in the past a few times when I accidentally did major damage to my own data during early testing of the backup/restore system. Basically I got the most recent months imported and cleaned up, and then gradually worked backwards in time from there when the mood took me.
For normal use of the app you don’t need every day’s data for the past 6 or so years. Most of the time you’re only looking at and caring about the more recent stuff. So there’s no urgent need to have it all in as quickly as possible. It’s certainly not ideal, but it would mean getting back to normal quickly, and setting aside the larger task as something to chip away at over time.
Though it’s important to make sure you import the data backwards in time sequentially, without skipping weeks. If the timeline processing engine sees a data gap between items it’ll try to “heal” over the gap, which can then make it difficult to import the missing data in later, because the gap for it is gone.
If you go the “long term project” way then you can basically treat your current import progress as “done”, then clean up what’s there and make the best sense of it, and go on recording new data without hassle. Then whenever the mood takes you import another week or two, without any pressure to get as much in as possible or as quickly as possible.
