Quote:
Originally Posted by ashadul
I was experimenting with my kobo touch to find out the cause of freezing problem and these are so far my findings:
1. Previously kobo used to save images on file system and now inside the database. This increase the database file size drastically. Disabling cover view on book list and compacting the sqlite database improves performance.
|
Where do you get that idea from? For books in the main memory, the generated cover images are stored in ".kobo_images". For books on the SD card, the covers are generated each time they are needed. A few are kept in the in-memory cache, but if you page through the library list, it will probably be generating cover images for each book on each page.
If you are using the SD card, you can speed up the lists using calibre. It can generate and send the to the device. If it finds them in the correct place, they will be used instead of being generated.
There is a table in the database called "Images". So far, it doesn't seem to be used. The columns are ImageId, Type, Width and Height. The ImageId will be the file name in the above directory.
Quote:
|
2. Kobo is keeping various activity logs in the database further increasing the database size. Manually deleting the logs and compacting helps.
|
Yes, that is correct. But, it will only really affect a couple of actions. There are problems with a couple of events. For them, they ContentID is set to null. What happens with these is that a row is added each time the event count is increased and all the rows have their event count increased. Event id 9 has been the biggest culprit for me. This counts the dictionary lookups or possible the number of times text is selected. I have found several thousand of these rows in the database. My fix was to delete all except one and set the ContentId to blank. From then on, it did the count but didn't duplicate the rows. And it improved the performance when looking up a word.
It's probably to late now, but it would be interesting to see the counts in the Event table. That would give an idea of what was happening and if anything was getting out of control.
If you think this is really a concern, you could add a trigger to prevent the rows being added to the Event table. The Kobo Utilities plugin for calibre has a function to do this for the AnalyticsEvents table. This was added as people wanted to prevent this data from being collected by Kobo.
Quote:
|
3. Reducing the no of books in the device and compacting helps even more.
|
Yes, bigger database means slower access. But, I currently have just short of 1000 books on my Glo, and about 1500 on the Touch. I don't see the problem you are seeing with either device. How many books did you have on it? And how big was the database?
Quote:
|
These cases makes me believe that database structure change without consideration to impact is the reason my freezing. (I hate to think inefficient SQL queries is the reason behind my problem though I made the same mistake once.)
|
Yes, there probably is some inefficient SQL in the firmware. I wish I could get a list of it all so I could have a play and work out how to improve it.
A problem with this as a conclusion is, why doesn't it happen for each page? If it is happening when changing chapters, that might make sense. The current position is stored in a database, so it probably gets stored when going to a new chapter. Otherwise, it gets stored during events such as closing the book, the device going to sleep or connecting to the PC.