Quote:
Originally Posted by Sefiriot
Aug 25-- yes, that would likely have been me. The above scenario sounds like the background to both crashes that wiped the database, now you mention it.
Backgrounding CC however... there could be several points where it could've happened because of something I did: it's on a phone, and I had several messages coming in that night I responded to while CC was working. Responding only takes a matter of seconds though, and CC came back and was still responding after each time I skipped out to WhatsApp.
I think the big one where manure finally hit the oscillating ventilation device would have been after calibre told me CC got disconnected, and CC was still stuck at the file transfer screen. I remember trying to get out to the home screen in hopes of restarting CC by force and failing: it was one of those really nasty hangs where hitting reset doesn't seem to work too well... IIRC it crashed soon after with a request to error report.
|
It might not be obvious that the db was closed. When you come back to CC, if necessary Android will restart it. The restart could mask the fact that the db went away while CC was in the background.
I have made a change to verify that the db is still open every time the db is used. This won't slow down the normal case because Android keeps a cache of open databases and gives the cached value back. If the database had been closed, then it will take a bit longer, but this is better than (sometimes silent) death. This change will be in the next CC release, something that should come near the end of the week.
I have also changed some things in when books being sent by calibre are stored into the DB. The existing version starts storing each book when the book arrives, something that works fine if the DB is running at full performance. However, if the DB has slowed down, then this method can make it even slower by having multiple "books" try to access the DB at the same time. It now uses a queue so only one book accesses the db at a time.