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.