- KOReader version:
- Device: Kobo Clara HD
Issue
Have completely switched over to koreader from kobo/nickel and am enjoying the software very much.
One issue is with the search calibre metadata functionality (i.e. browse series), despite deleting and having calibre recreate the driveinfo.calibre and metadata.calibre files. The metadata in calibre exists and is in good order.
When I use the calibre->search settings -> manage libraries -> rescan disk for calibre libraries option, the resulting message says, "Found 1 calibre library with 1 books: 1: /mnt/onboard
The actual calibre library (and the device) holds 3261 books.
crash.log (if applicable)
The following crash log is of an actual crash, but repeating the attempt to scan the calibre libraries does not always generate the crash.
crash.log
04/17/22-14:59:12 WARN cache is older than metadata, ignoring it
04/17/22-14:59:38 INFO calibre info loaded from disk (search) in 26244.237 milliseconds: 1 books
04/17/22-14:59:39 INFO metadata: 1 books imported from calibre in 28796.470 milliseconds
./luajit: not enough memory
!!!!
Uh oh, something went awry... (Crash n°1: 04/17/22 @ 14:59:43)
Running FW 4.30.18838 on Linux 4.1.15-00089-ga2737fc02713 (#34 SMP PREEMPT Fri Dec 27 17:47:13 CST 2019)
Attempting to restart KOReader . . .
!!!!
Thanks for any insight into this issue.
Issue
Have completely switched over to koreader from kobo/nickel and am enjoying the software very much.
One issue is with the search calibre metadata functionality (i.e. browse series), despite deleting and having calibre recreate the driveinfo.calibre and metadata.calibre files. The metadata in calibre exists and is in good order.
When I use the calibre->search settings -> manage libraries -> rescan disk for calibre libraries option, the resulting message says, "Found 1 calibre library with 1 books: 1: /mnt/onboard
The actual calibre library (and the device) holds 3261 books.
crash.log(if applicable)The following crash log is of an actual crash, but repeating the attempt to scan the calibre libraries does not always generate the crash.
crash.log
Thanks for any insight into this issue.