MobileRead Forums - View Single Post - Kobo Glo

davidfor · 08-31-2013, 07:31 AM

BobC, I could see that as a problem, but it doesn't explain why so few people are seeing this problem. It also doesn't explain why so many of them are running XP. It would also make more sense if it was the first interaction with the database rather than one several minutes later.

Your suggestion that you can defer the problem by vacuuming the database suggests that it isn't a conflict with something still running on the device. As the vacuum is a complete read and write of the database, then that should contend with anything happening on the device.

The difference with how calibre hits the database and a vacuum is the smaller updates. Each change made by calibre will cause a write to the database file. It also creates a journal file that disappears quickly. Maybe the issue is the flood of small writes to a large file and the small journal files at the same time.

Experiments I can think of:

- Connect the device without calibre running. Wait ten minutes or more and start calibre. If there was a process still running on the device, hopefully it will have finished by this time.

- Run a set of database updates from some other application than calibre and see what happens. Doing a select from the ShelfContent table followed by an insert into it followed by a commit and repeating a lot of times would match what has been reported as a common timing of the problem.

08-31-2013, 07:31 AM	#14
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	BobC, I could see that as a problem, but it doesn't explain why so few people are seeing this problem. It also doesn't explain why so many of them are running XP. It would also make more sense if it was the first interaction with the database rather than one several minutes later. Your suggestion that you can defer the problem by vacuuming the database suggests that it isn't a conflict with something still running on the device. As the vacuum is a complete read and write of the database, then that should contend with anything happening on the device. The difference with how calibre hits the database and a vacuum is the smaller updates. Each change made by calibre will cause a write to the database file. It also creates a journal file that disappears quickly. Maybe the issue is the flood of small writes to a large file and the small journal files at the same time. Experiments I can think of: - Connect the device without calibre running. Wait ten minutes or more and start calibre. If there was a process still running on the device, hopefully it will have finished by this time. - Run a set of database updates from some other application than calibre and see what happens. Doing a select from the ShelfContent table followed by an insert into it followed by a commit and repeating a lot of times would match what has been reported as a common timing of the problem.