Libra Kobo Libra factory reset itself?

[mathil]

Well, I've just had my very first forced restore on a Kobo in... 7 years I think?

Latest firmware installed, patches applied, Windows 10 64-bit laptop with Calibre 5.5. I wasn't doing anything unusual - I had the reader connected to Calibre so I could send over a couple of books, and while I was at it I copied over a couple of .otf fonts (acquired normally, no shady sources). Something I've done dozens of times and never had a problem with. Made sure to eject and disconnect the device properlym when there was no communication with the device.

What happened next is that the usual loading screen appeared and the progress seemed to go on as slow as molasses. When that was over the device reset and showed me the language choice screen, appearing to have restored itself to factory default - but when I went over the steps required to connect it to the Wi-Fi network it remembered the password, told me the device was up-to-date and the loading screen started again. At that point I forced a reset with page button+power button and the device turned on normally showing me only 100 ca. books of the 3000 I had loaded on the device (some sideloaded, some from my Kobo account). I ended up restoring it to factory default manually to make sure everything was okay.

So, problem solved (I guess...) but - what do you guys think happened? I assume it was a database corruption, but I have no idea how that could have happened, considering I made sure to follow all of the proper steps before disconnecting the device from my laptop. The font files are fine; I checked the .epub files I sent over with EpubCheck and there are no errors. Any ideas?

[davidfor]

The most likely thing is that something happened to restart the device. When it tried to read the database to get whatever it needs, it couldn't. That triggered the setup process being called. It probably also cleared the .kobo and .kobo-images directory. The rest was it doing the setup.

As part of the setup, it should have downloaded the details of your purchased books and the file for five books. These are usually the five most recent books according to the "Recent" sorting. Then it should have imported all your sideloaded books. But, you interrupted that. Hence, the only imported books where the ones it had imported before you forced the restart. If you had connected to the computer, the import would have started again when you disconnected the device. But, it is possible that forcing the restart, would have damaged the database eventually putting you back in the original state.

What initially happened, I don't know. If the importing was going slow, it could be that there was already a problem with the database. Or the books you sideloaded were a bit bigger than usual or had some problems making the import slower than usual. There is a process that will restart the device if there is a hung process. That might be why it restarted. At this point, there is no real way to check.

[NiLuJe]

Hmm, yeah, sickel rebooting the device because of a hung nickel during the import process could indeed produce something like that, I guess...

[compurandom]

Usually the database corruption is caused by not ejecting properly. For a while, calibre wasn't ejecting properly for me -- it said it was, but the OS didn't eject it. I assume this was some corrupted setting in calibre, because it went away. But now, if I miss the eject noise, I get paranoid and double check that the OS has ejected it.

[Quoth]

I think it was nothing to do with Calibre, but an OS & Kobo issue fixed on a Kobo FW update.

[compurandom]

Originally Posted by Quoth

I think it was nothing to do with Calibre, but an OS & Kobo issue fixed on a Kobo FW update.

There's been some of those too, but I actually tested with calibre 5 and repeatedly watched it not eject the device when it said it ejected it.
Then I switched to calibre 4.23 to see if it had the bug too (it didn't), and then switched back to calibre 5 and couldn't repeat it. So the only conclusion I can reach is that something in the shared config between calibre 4/5 was corrupt and calibre 4 fixed it. I wish I had copied the config so I could diff it, but oh well.

I suppose it could have been a config problem on the device that calibre 4 fixed.

[davidfor]

Originally Posted by compurandom

There's been some of those too, but I actually tested with calibre 5 and repeatedly watched it not eject the device when it said it ejected it.
Then I switched to calibre 4.23 to see if it had the bug too (it didn't), and then switched back to calibre 5 and couldn't repeat it. So the only conclusion I can reach is that something in the shared config between calibre 4/5 was corrupt and calibre 4 fixed it. I wish I had copied the config so I could diff it, but oh well.

I suppose it could have been a config problem on the device that calibre 4 fixed.

For me, if I eject from calibre and the device doesn't actually eject, it means that something else is using the device. That usually means I opened the database to look at and forgot to close it, but it can be something else. In those cases, I need to close whatever it is and then use Windows to eject the device.

In your case, I doubt it was something in the configuration. Maybe a library wasn't replaced. But, it would have been interesting to see what it was that was blocking the eject. Probably an open file, but what was doing this is the question.

[compurandom]

Originally Posted by davidfor

In your case, I doubt it was something in the configuration. Maybe a library wasn't replaced.

I have calibre 4 and 5 both installed.
Calibre 4 in its own directory, calibre 5 is a fresh install in the default directory.

But, it would have been interesting to see what it was that was blocking the eject. Probably an open file, but what was doing this is the question.

I know how to check for open files and seek out what has them open.

Just for fun, I just left a window in the root directory of the kobo and asked calibre to eject. Much to my surprise, it ejected it, invalidating the directory from under the shell. Never seen that before. So now I'm even more confused. (I think I upgraded to 5.6 today or yesterday.)

[davidfor]

Originally Posted by compurandom

I have calibre 4 and 5 both installed.
Calibre 4 in its own directory, calibre 5 is a fresh install in the default directory.

I assume one of those is a portable version. If not, there might be some interesting things happen with respect to exactly which libraries are being used.

I know how to check for open files and seek out what has them open.

Just for fun, I just left a window in the root directory of the kobo and asked calibre to eject. Much to my surprise, it ejected it, invalidating the directory from under the shell. Never seen that before. So now I'm even more confused. (I think I upgraded to 5.6 today or yesterday.)

That's what I usually see. Explorer will usually allow it to eject, but an open command-line will block it. If a file is open in Notepad++ it will eject, but, the calibre editor will block it.

[compurandom]

Originally Posted by davidfor

I assume one of those is a portable version. If not, there might be some interesting things happen with respect to exactly which libraries are being used.

Calibre 5 was installed as root.
Calibre 4 was installed as a regular user.

I'm not sure how libraries would overlap, as neither one installed any global libraries, but if there's any overlap, calibre 5 should be what is used.

That's what I usually see. Explorer will usually allow it to eject, but an open command-line will block it. If a file is open in Notepad++ it will eject, but, the calibre editor will block it.

But it was a command line that had the directory open...and it ejected anyway. Like I said, I've never seen that before.

[jotekman]

Mathil- exact same thing happened to me today. Kind of strange it would happen to both of us right after a firmware update. I also ejected my Kobo from Calibre, yet it worked, but i could see the file in the main window, but literally none of my books. It then crashed, and reset. sigh.

[compurandom]

Originally Posted by jotekman

Mathil- exact same thing happened to me today. Kind of strange it would happen to both of us right after a firmware update.

Not that strange. Database corruption issues are usually only noticed after a reboot. So if you never reboot and your database gets corrupted, then things go sideways when it reboots after the firmware upgrade.

Although I've had some database corruptions so bad that the device crashed and rebooted, and _then_ noticed it was corrupt.

I think one of the times it logged me out after a database corruption, I managed to side load restore the database and config file and didn't have to re-log in, so it wasn't too big a deal except for kobo books and pocket articles needing to re-download.

[retro]

This has happened with my Clara several times. I have 2 libraries in one instance of Calibre. What I noticed was that if I switch libraries with the Clara connected, add books from both and then disconnect, it resets or corrupts the BookReader.sqlite database.

It seems that some settings can be different in each library, even though there's one instance of Calibre. I have been going through all the settings and making changes so they match. Also, I have not switched libraries when connected. So far the corrupted database error and resets have stopped.

[davidfor]

Originally Posted by retro

This has happened with my Clara several times. I have 2 libraries in one instance of Calibre. What I noticed was that if I switch libraries with the Clara connected, add books from both and then disconnect, it resets or corrupts the BookReader.sqlite database.

ABSOLUTELY NOT. Please, read this carefully as I am completely sick of you saying this:

NOTHING in calibre, the Kobo related drivers or plugins know anything about the BookReader.sqlite. The do not have any code that goes near it. They do not open it. The do not even know it exists. If this file is being corrupted, it is NOT being done by calibre.

If the BookReader.sqlite is being corrupted, it is by something else.

[NiLuJe]

Wild guess: if you're on Windows/macOS, as it's encrypted, it might very well be tickling the fancy of some crappy AV software or some such to go screw with it....