Hi davidfor, thanks for the response.
Quote:
Originally Posted by davidfor
The usual reason for the database getting corrupted is not ejecting the device correctly. If you are doing that each time, there shouldn't be a problem. How are you ejecting? From calibre or from the OS?
|
I am usually ejecting from calibre, then verifying it from the OS. In any case, Linux does confirm that the drive is unmounted before I pull the plug.
Quote:
Originally Posted by davidfor
How often do you need to connect to calibre for this to happen? Do the problems start appearing as soon as the device restarts after the connection, or does it take a while? And what happens the next time you connect? Do you use the Kobo desktop app at all? Have you had any hangs in the device?
|
I need to connect to calibre once before this happens. Any modification of the onboard database will cause this error. The error exists immediately after disconnecting (verified by transferring the database via FTP and examining it with sqlite and by examining the onboard partition without calibre enabled). The next time I connect the device to calibre the driver cannot load the metadata and complains that the database is corrupted.
No filesystem errors are present; the error is limited to the database contents.
I do not use the Desktop App (I don't have any purchased kepubs).
No hangs on the device, except if the corrupted database is used.
Quote:
Originally Posted by davidfor
After this happens, what are you doing to fix it? Are you logging out on the device, or doing a factory reset? The logout should be all that is needed as it replaces the database on the device with a new one. If it continuously happens, a factory reset would be the way to go and see what happens afterwards.
|
My kobo creates a backup of the database each day (first boot). I simply log in via telnet, cp the backup to the original and reboot. After that, the problem is fixed.
I cannot really logout, as I am "logged in" as foo@bar
I'm really no fan of the kobo connectivity features.
Quote:
Originally Posted by davidfor
It is possible there is a file system problem. Try doing a scandisk when it next happens. If you are using Windows, it should prompt you if there is an issue, but sometimes it doesn't.
|
No, it is definetely not a filesystem error (fsck -t vfat). The error is limited to the format of the database.
Quote:
Originally Posted by davidfor
The driver options shouldn't be a problem. But, uncheck the "Attempt to support newer firmware". I am keeping the driver up to date, but if Kobo slip an update in when I'm not looking, having this on could cause a problem.
The DBVersion is OK. The code checks this and changes what it will do based on the different DBVersions.
The next time this happens, can you send me the devices database? When you see problems on the device, connect without calibre running and take a copy of the database. Send me a PM to get an address to send it to or a link that I can download it from. From the errors in the database, I might be able to see what is happening.
|
I can reproduce the error at any time without any real harm, so of course I can send you a copy of the database. Won't be before the next sunday though, as my girlfriend kidnapped the KT for a fieldtrip.
Quote:
Originally Posted by davidfor
That probably isn't much help. But, I can't think of anything else at the moment. If I think of something else, I will tell you.
|
I have another thought to offer, but this is rather speculative. I did try to manually set series information (as in "UPDATE content SET Series="blah",SeriesNumer="1" where...") some time ago. This was before I updated my calibre from version 5something to 9.19 and I had not even heard of your driver yet. I vaguely remember that after that, something was wrong with the database and that caused me to create the backup script in the first place. So it may be that the series information causes nickel to corrupt the database itself. Of course that would mean that simply disabling the "Set Series information" option in the driver would also fix the problem... I will test that hypothesis in a week and report the results.
Thank you non the less for your help davidfor. Altogether i would like to point out that I really appreciate your work on this driver and you have done a great job. I just have a nag for producing weird errors.