MobileRead Forums - View Single Post

davidfor · 08-22-2021, 10:35 AM

@Cootey: Reading through that, there is only one thing I can say: I have absolutely no idea what is happening. None of it makes sense as it works fine for the other devices. It seems to be something different about the Elipsa. Whether it is related to how the device connects to the PC or something else running that correctly connect or disconnect from the database I don't know.

For debugging this, I gave all my ideas earlier. At best it tells you what sort of action is triggering it. The calibre debug logs are not going to tell us anything more than what you have shown. They are basically showing an error when it happens, and what happens before that is exactly what is expected. You can produce logs on the device, but, they are encrypted and I have no way to decrypt them to see what is in them. You can redirect the log (I think there is a NickelMenu function to do it) but whether that will show anything useful I don't know. Before Kobo started encrypting the logs, I never saw anything that would give a clue for why the corruption happened. But, I don't know if I ever saw logs from when it happened.

I don't believe it it calibre. If it was, we would be seeing a similar rate of database corruption for other devices. The only thing calibre does differently for each device is the sizes for covers if you send them to the device. And the name displayed when the device is connected. Nothing else is different.

As to doing a "VACUUM", that is the command you would use in a SQLite management tool or command-line SQLite. In the Kobo Utilities plugin, it is the compress option as that is what I am used to for other databases.

08-22-2021, 10:35 AM	#34
davidfor Grand Sorcerer Posts: 24,905 Karma: 47303824 Join Date: Jul 2011 Location: Sydney, Australia Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos	@Cootey: Reading through that, there is only one thing I can say: I have absolutely no idea what is happening. None of it makes sense as it works fine for the other devices. It seems to be something different about the Elipsa. Whether it is related to how the device connects to the PC or something else running that correctly connect or disconnect from the database I don't know. For debugging this, I gave all my ideas earlier. At best it tells you what sort of action is triggering it. The calibre debug logs are not going to tell us anything more than what you have shown. They are basically showing an error when it happens, and what happens before that is exactly what is expected. You can produce logs on the device, but, they are encrypted and I have no way to decrypt them to see what is in them. You can redirect the log (I think there is a NickelMenu function to do it) but whether that will show anything useful I don't know. Before Kobo started encrypting the logs, I never saw anything that would give a clue for why the corruption happened. But, I don't know if I ever saw logs from when it happened. I don't believe it it calibre. If it was, we would be seeing a similar rate of database corruption for other devices. The only thing calibre does differently for each device is the sizes for covers if you send them to the device. And the name displayed when the device is connected. Nothing else is different. As to doing a "VACUUM", that is the command you would use in a SQLite management tool or command-line SQLite. In the Kobo Utilities plugin, it is the compress option as that is what I am used to for other databases.