Elipsa Ghost eBook Purchase on an Elipsa

[davidfor]

Originally Posted by Cootey

That’s fascinating that you were able to reproduce the issue with DB Browser.

You sound surprised and I don't know why. My tests says that if I read a CBZ, connect to a PC and do something to update the database, I will probably have a corrupt database. It doesn't matter how I do that, just that I do.

Is this a problem with just the Elipsa, or with all Kobos running the 4.28.x firmware?

I don't have an Elipsa. From memory, I did it with my Clara HD, Aura ONE and Glo.

And while I didn't test, I don't think this is just a 4.28.x issue. I am told the problem has been in the firmware for a long time. Possibly from the start. That suggests it is would have happened with any firmware. And it might explain some seemingly random problems people have complained about.

Since the database is being left open by the Kobo, would we be able to avoid corruption by power cycling the Kobo before connecting to a computer?

Probably. Assuming everything gets closed down properly, it should work. It's also possible it will close after some time, or if you open some non-CBZ books.

I’ll probably give Kobo a call and update one of the cases I had open with them. It couldn’t hurt.

[NiLuJe]

Yup, power cycling works .

(As does simply killing nickel, obviously).

My current workaround is simply to handle USBMS inside KOReader, then do Library scans in Nickel via NickelMenu (... then don't forget to do the next USBMS session inside KOReader if new CBZs were scanned).

[Cootey]

Originally Posted by davidfor

You sound surprised and I don't know why. My tests says that if I read a CBZ, connect to a PC and do something to update the database, I will probably have a corrupt database. It doesn't matter how I do that, just that I do.

I don't have an Elipsa. From memory, I did it with my Clara HD, Aura ONE and Glo.

And while I didn't test, I don't think this is just a 4.28.x issue. I am told the problem has been in the firmware for a long time. Possibly from the start. That suggests it is would have happened with any firmware. And it might explain some seemingly random problems people have complained about.

I wasn't surprised. I just found it fascinating that thought to do it. Since I didn't know that the CBZ files were at fault, I never directly tried to test other apps beyond Calibre to trigger a database corruption as you did.

I know I've never experienced a corrupt database with my Clara, and I've read CBZ files on it. I only encountered this issue with Elipsa. This indicates to me that the problem was introduced later. I eventually stopped bothering to read comics on my Clara–too small! So it had been an indeterminate but long period of time between when I stopped loading CBZ on my Clara (with no database corruption) and when I bought the Elipsa and immediately ran into issues. As I was reading comics on my Clara and side loading more using Calibre, I should have run into the database corruption issue. But I didn't. My Elipsa, OTOH, just had to be in the vicinity of my Mac to suddenly become corrupt, or at least that's what it felt like.

Earlier I mentioned that I would restore the Elipsa from backup after a corruption event and encounter markup files loaded as books, both the screen shots and the vector files. That happened again the other day. I have a theory about what might be happening.

Markups on sideloaded books are not restored after a factory reset, which is disappointing but similar to how annotations are treated for sideloaded books. Is it possible that the remnants of unrestored markups get treated as books instead? Unfortunately, I did not think to examine the markups to see which books they came from (downloaded vs sideloaded). My attempt to restore the Elipsa with a backup doesn't work because of this issue.

[Cootey]

Originally Posted by NiLuJe

Yup, power cycling works .

(As does simply killing nickel, obviously).

My current workaround is simply to handle USBMS inside KOReader, then do Library scans in Nickel via NickelMenu (... then don't forget to do the next USBMS session inside KOReader if new CBZs were scanned).

Thanks for verifying that. Since I've already removed all CBZ files from my Elipsa, I won't need to try this out, but there's a high chance I'd likely forget to power cycle and muck things up before plugging it in.

[Cootey]

With surgery and COVID-19, I have been out of sorts for the past two months. Has there been any update on this problem? Powercycling before syncing has prevented any further db catastrophes, but I'd love to see this problem fixed. I just don't dare test it by not power cycling first! I also filed a bug report with Kobo Customer Support, but nobody contacted me about it despite the assurances of the CS reps. ¯\_(ツ)_/¯

Also, what other Kobos does this bug affect?

[DNSB]

Originally Posted by Cootey

With surgery and COVID-19, I have been out of sorts for the past two months. Has there been any update on this problem? Powercycling before syncing has prevented any further db catastrophes, but I'd love to see this problem fixed. I just don't dare test it by not power cycling first! I also filed a bug report with Kobo Customer Support, but nobody contacted me about it despite the assurances of the CS reps. ¯\_(ツ)_/¯

Also, what other Kobos does this bug affect?

As far as I am aware, the 4.30.18838 firmware release has fixed the database corruption issue with CBZ files.

[davidfor]

Originally Posted by DNSB

As far as I am aware, the 4.30.18838 firmware release has fixed the database corruption issue with CBZ files.

I've tested it a bit and have not had a single problem after opening CBZ or CBR files.