Firmware 4.31.19086

[MGlitch]

Originally Posted by compurandom

Well, consider this a "much more report".

And I'll report that this is an issue from before 30, let alone 31.
It just isn't as frequent.

To be more specific, more users reporting it more frequently. Rather than a handful (who didn't intentionally try and trigger this) reporting more frequently.

The bug is def. there, it's just curious that we've seen fairly little noise about it. I'm sure it's been mentioned, but could Windows scanning the partition be part of the issue? That would at least explain why multiple thousands of books getting imported to my Libra 2 the other day didn't make it bat an eye, nor did ejecting while in a kepub, as I'm doing it all on a Mac.

[Poppaea]

Originally Posted by MGlitch

To be more specific, more users reporting it more frequently. Rather than a handful (who didn't intentionally try and trigger this) reporting more frequently.

The bug is def. there, it's just curious that we've seen fairly little noise about it. I'm sure it's been mentioned, but could Windows scanning the partition be part of the issue? That would at least explain why multiple thousands of books getting imported to my Libra 2 the other day didn't make it bat an eye, nor did ejecting while in a kepub, as I'm doing it all on a Mac.

When I got my Libra 2, I imported a couple of hundred books in one go. I didn't send all my books at once because I then was still sorting them manually into collections on the reader, which takes time. Then the next couple hundred and so on, until I had about a thousand books on it.

I can't say with confidence it went worse with each batch, because I neither did keep a close eye on it nor did I write anything down, so this is just my memory of how things happened. But the crashing while still indexing, books not showing up until the reader was connected again (without re-sending them) to be visible on the reader, the warning message, all this happened more and more. So factory reset the whole reader back twice and went through the whole thing once again after the first reset with the same occurrences and results. After the second reset, I changed to 4.30 and have not encountered any of this.

I can't give any numbers or help with the codes, so I know this is clealy only anecdotal, but I still hope this helps.

My guess is if you were to add a more books to it and keep on doing so, it would trigger this for you too.

ETA All my books are kepub

[John F]

I'm back on 4.30.x (on a Forma) and I haven't had any database corruption issues. I don't recall ever having a database corruption issue. I use calibre and calibre's eject the vast majority of the time. I usually transfer a small number of books at a time and I'm usually reading when I plug it in (as opposed to being on the home screen). I wait for the covers to update in the My Books section on the home screen before doing anything with the Forma. I use kepubs generated on the fly.

Also, calibre/Windows doesn't give me any "it is safe to remove ..." message after I eject using calibre.

[ZodWallop]

Originally Posted by John F

Also, calibre/Windows doesn't give me any "it is safe to remove ..." message after I eject using calibre.

Yeah, I've never had such a message from Windows when I eject using Calibre. To get the Windows message, I would have to use the Eject icon in the Widnows taskbar.

[icallaci]

Originally Posted by ZodWallop

Yeah, I've never had such a message from Windows when I eject using Calibre. To get the Windows message, I would have to use the Eject icon in the Widnows taskbar.

Same here. After I started experiencing problems with 4.31, I stopped using Calibre to eject (to see if that was causing it) and started using eject from the Windows taskbar. It didn't seem to make any difference, so I am back to using Calibre to eject and waiting for the import process to complete on the reader before removing the cable. I never just yank the cable out. But nothing seems to make a difference. The scan problem is there every single time I add one or more books, unless I power off the reader, then power it back on.

[frostschutz]

Originally Posted by ownedbycats

Sometimes I connect from the home screen and sometimes I connect while I'm reading a book
[...] I guess I could manually copy some random ePub onto my device.

Please try it, would be interesting to know if it actually makes a difference.

After all my test results could also be related to enabled telnet access and such, or some other specific configuration. You never know which settings might influence whatever nickel is doing internally.

So it would be interesting to know if others can reproduce it at all, i.e. whether connecting USB from within regular EPUB2 file (instead from kepub or home menu or elsewhere) makes any difference regarding filesystem checks / corruptions.

[frostschutz]

Originally Posted by davidfor

My shell scripting is terrible. But, in the 4.31 version, I think that means if one of the commands fails, the later commands are not executed. Whereas in the 4.30 version, they will all execute no matter what.

My best guess is that it's a speed optimization, insmod seems to be quite slow even if it fails and if it's going to fail anyway (as is the case on the Libra 2), no point in making the subsequent attempts.

[jackie_w]

Originally Posted by frostschutz

Please try it, would be interesting to know if it actually makes a difference.

After all my test results could also be related to enabled telnet access and such, or some other specific configuration. You never know which settings might influence whatever nickel is doing internally.

So it would be interesting to know if others can reproduce it at all, i.e. whether connecting USB from within regular EPUB2 file (instead from kepub or home menu or elsewhere) makes any difference regarding filesystem checks / corruptions.

Funnily enough I did some tests a few days ago with 4.31 on a Libra2.

Every time I connected USB from:

• inside a book (kepub) I *did* get the Windows scan/fix message.
  
• Home screen or MyBooks I *did not* get the scan/fix message.

I have not had any database corruption with 4.31 but I've probably only sideloaded (via calibre) about 10 kepubs since upgrading to 4.31.

What I have had is the Libra2 freezing a few times. A simple reboot fixed it with the only "damage" being loss of current reading position in the book I had open when it froze. I think the freezes have always happened after I got distracted by something else and hadn't touched the reader for a few minutes.

[RobertJSawyer]

I do a lot of switching back and forth between books (all Kepubs synched from the Kobo store) and articles from Pocket, and get a lock-up requiring a reboot on my Libra 2 about once a day. Unfortunately, I've yet to discern any pattern to when the lockup occurs.

[ownedbycats]

Originally Posted by jackie_w

Every time I connected USB from:

• inside a book (kepub) I *did* get the Windows scan/fix message.
  
• Home screen or MyBooks I *did not* get the scan/fix message.

I can confirm this.

[DNSB]

One addition I've made to my NickelMenu options is:

#
menu_item : main    : Free Memory        : cmd_output   : 500: free -m
#
menu_item : reader  : Free Memory        : cmd_output   : 500: free -m
#
menu_item : library : Free Memory        : cmd_output   : 500: free -m
#

At some points, I've had the available memory drop to below 9MB and often after switching fonts a couple of time, I've seen reboots. Heck, switching to Arial Unicode MS after reading a couple of pages can trigger a reboot 4 times out of 5 while switching from CharEink to Amasis to Georgia to AR Ming is rather reliable at triggering a lock up.

[rtiangha]

Originally Posted by DNSB

At some points, I've had the available memory drop to below 9MB and often after switching fonts a couple of time, I've seen reboots. Heck, switching to Arial Unicode MS after reading a couple of pages can trigger a reboot 4 times out of 5 while switching from CharEink to Amasis to Georgia to AR Ming is rather reliable at triggering a lock up.

I've noticed the same (well, locking up; I've mangled sickel so it doesn't reboot) with fonts or opening kepubs with a lot of large image files (closing the book didn't seem to free up much memory), and my only recourse was either rebooting or killing/restarting nickel.

[ownedbycats]

Originally Posted by frostschutz

Please try it, would be interesting to know if it actually makes a difference.

I loaded up a ePub book (if any matter, an Overdrive loan) then did some connects/disconnects; didn't do anything else aside from Kobo Utilities fetching the reading status. Observations:

Connecting while the ePub is open doesn't trigger scan&fix.

Connecting while a kepub is open always triggers scan&fix.

Connecting with the home/books menu open sometimes triggers scan&fix; no database corruption during these tests (phew), but in the past I've noticed it was more likely but not guaranteed that Calibre/Kobo Utilities would then report some database problem. Restoring the last good backup always fixed it for me.

[compurandom]

I bet that it requires a combination of events to trigger database corruption.

Something like:
* books recently imported or position within a book recently saved or books recently deleted or import recently completed (but none of those flushed to disk yet)
* either reading a book (so database is held open) or cover generation in progress, or something else running in the background, any of which might prevent the disk from being unmounted and buffers flushed
* USB connect attempted before the above complete...

In that state, you might have the host and the kobo both having the disk open, and the database could get corrupted.

[ownedbycats]

Kobo uses SQLite.The documentation has a list of very specific ways corruption may occur.