Mobileread
Libra Kobo Libra factory reset itself?
#1  mathil 11-26-2020, 06:33 PM
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?
Reply 

#2  davidfor 11-26-2020, 08:23 PM
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.
Reply 

#3  NiLuJe 11-26-2020, 09:09 PM
Hmm, yeah, sickel rebooting the device because of a hung nickel during the import process could indeed produce something like that, I guess...
Reply 

#4  compurandom 11-29-2020, 11:15 AM
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.
Reply 

#5  Quoth 11-29-2020, 12:00 PM
I think it was nothing to do with Calibre, but an OS & Kobo issue fixed on a Kobo FW update.
Reply 

#6  compurandom 11-29-2020, 05:15 PM
Quote 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.
Reply 

#7  davidfor 11-29-2020, 10:24 PM
Quote 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.
Reply 

#8  compurandom 11-30-2020, 02:25 AM
Quote 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.

Quote
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.)
Reply 

#9  davidfor 11-30-2020, 03:30 AM
Quote 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.
Quote
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.
Reply 

#10  compurandom 11-30-2020, 08:09 AM
Quote 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.

Quote
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.
Reply 

  Next »  Last »  (1/2)
Today's Posts | Search this Thread | Login | Register