Kobo Bug thread

[dimm]

Originally Posted by Lucas Malor

Does it log also identical searches (same book, same string) to different rows?

All these events (of type 9) are identical. Besides, this table contain also other events. Mine was 6168, from which 6000 - was identical records of type 9.

[davidfor]

Originally Posted by Lucas Malor

This is very strange. What is the convenience to have a lookup table without the searched string? Maybe they have created another table, but why?

They aren't recording the words you look up. One of the things the Event table is used for is the Awards. The "Word Up!" award is given after 10 dictionary look ups. When the EventCount on the EventTpe 9 row reaches 10, you get the award. After that, it just keeps counting the lookups.

You said "The database updates tend to be an insert and a delete, rather than updating the existing row". Do you intercepted the firmware queries?

No, from inspecting the database. I can see that for most updates, a row has been added to the end of the table, rather than updating where it was before. I am not completely certain that this is what is happening, but based on what I see, it is probably right.

[davidfor]

Originally Posted by dimm

All these events (of type 9) are identical. Besides, this table contain also other events. Mine was 6168, from which 6000 - was identical records of type 9.

Whatever they are doing with those rows is weird. I deleted all except one row. After a few dictionary lookup, that row was unchanged, but the new ones where all 1 higher than it. I thought it might have been recording all lookups, but only counting the lookups in kepubs. A quick test showed that doesn't seem to be the case.

[tshering]

Originally Posted by davidfor

When the EventCount on the EventTpe 9 row reaches 10, you get the award. After that, it just keeps counting the lookups.

It seems that in previous FWs counting was stopped after reaching 10. So at least after 10 look-ups, there was no more writing to the db.

[davidfor]

Originally Posted by tshering

It seems that in previous FWs counting was stopped after reaching 10. So at least after 10 look-ups, there was no more writing to the db.

I can't say I noticed that. Any idea what FW it was?

[tshering]

Originally Posted by davidfor

I can't say I noticed that. Any idea what FW it was?

I am now at 2.4.0. I have only one EventType 9 entry, the count is 10, and the date is older than 1 month. I am using the dictionary almost every day.

[davidfor]

Originally Posted by tshering

I am now at 2.4.0. I have only one EventType 9 entry, the count is 10, and the date is older than 1 month. I am using the dictionary almost every day.

Interesting. I reset my Touch over the weekend, but hadn't done any reading with it. There was no EventType 9 rows, but a few dictionary lookups and I had one row with count of 17. I have deleted the rows from the Glo as well. I'll see what happens.

[tshering]

Originally Posted by davidfor

There was no EventType 9 rows, but a few dictionary lookups and I had one row with count of 17.

I am not sure what you are saying here. Are there other EventTypes associated with dictionary look-ups? And how is this count of 17 related?
I looked into a backup copy of the db from the short time when I used FW 2.5.0. There is exactly one EventType 9, and the EventCount is 10. So this bug seems to have been introduced later.

[tshering]

Now I looked up an older packup. Don't know the FW, but db version is 55. There I have one EventType 9 with EventCount 460.

[davidfor]

Originally Posted by tshering

I am not sure what you are saying here. Are there other EventTypes associated with dictionary look-ups? And how is this count of 17 related?

Just that with the firmware on the Touch, it only used one row but counted past 10.

I looked into a backup copy of the db from the short time when I used FW 2.5.0. There is exactly one EventType 9, and the EventCount is 10. So this bug seems to have been introduced later.

I have some backups going way back to 2.0.4. They all have multiple EventType 9. The EventCount for all of them is a lot higher than 10.

Maybe it is "Reading Life". Do you happen to have that on or off?

[tshering]

Originally Posted by davidfor

Maybe it is "Reading Life". Do you happen to have that on or off?

Good idea! I have it off.
Edit: I switched Reading Life on and did some dictionary look-ups. EventCount is now on 19. Still only one EventType 9. My assumption that a previous FW stopped registering dictionary look-ups after 10 proved wrong. So it seems, it was by chance that I switched Reading Life off after exactly 10 dictionary look-ups. Or does it count until 10 independent of the reading life setting? I am not going to check this now.

[Lucas Malor]

Probably we want to collect some statistics about dictionary lookup, so they can sort them by usage and date.

[davidfor]

Originally Posted by tshering

Good idea! I have it off.
Edit: I switched Reading Life on and did some dictionary look-ups. EventCount is now on 19. Still only one EventType 9. My assumption that a previous FW stopped registering dictionary look-ups after 10 proved wrong. So it seems, it was by chance that I switched Reading Life off after exactly 10 dictionary look-ups. Or does it count until 10 independent of the reading life setting? I am not going to check this now.

I just deleted the EventType=9 rows, changed the Achievement entry for the Award to 0% complete and turned of Reading Life. With that, when I did a few dictionary lookup, no EventType=9 rows were created.

Originally Posted by Lucas Malor

Probably we want to collect some statistics about dictionary lookup, so they can sort them by usage and date.

The data doesn't look right for that. They aren't storing the word that was looked up or the book. And the rows all have the same EventCount. While they can see when I looked up a word, I'm not sure how useful that is. As we have shown the extra rows are not always added, it seems to be a bug to add them.

[Lucas Malor]

I get a look to my db (I have firmware 2.4): there's only one EventType=9 row, that is updated every time I search in dictionaries. There's also an ExtraData column, that seems empty. There's no related trigger under the Master Table. I have not found any dicionary word inside the db... maybe they are stored outside?

PS: searched strings can be associated to the event table row through the ID.

[davidfor]

Originally Posted by Lucas Malor

I get a look to my db (I have firmware 2.4): there's only one EventType=9 row, that is updated every time I search in dictionaries. There's also an ExtraData column, that seems empty. There's no related trigger under the Master Table. I have not found any dicionary word inside the db... maybe they are stored outside?

PS: searched strings can be associated to the event table row through the ID.

Why do you think the looked up term is stored somewhere? I know I said recently they were, but tshering corrected me on it. The search terms are stored, not dictionary look ups.

No, there isn't a useful key. The primary key is EventType plus ContentID. For EventType=9, ContentID is always blank. The row isn't updated, it is deleted and a new one is insert. You can tell that from the rowid. If the row was updated, this wouldn't change. Because of that, the rowid isn't useful elsewhere. It could be used, but it would be a pain

And the mention of the primary key tells me what I think has happened. In all the duplicates in my backup databases, the ContentID is NULL. That is allowing multiple rows in the database with the same EventType. I deleted all the EventType=9 rows the other night and the new has an empty string for the ContentID. There can only be one of those in the database. I would say that sometime in the distant past, a firmware version erroneously inserted the row with NULL ContentID. The code obviously doesn't handle this correctly and didn't delete the rows but was able to insert the new row. The new row was probably created from the memory copy of the row read from the database, and hence inherited the null ContentID.

This also explains the performance problem. I have a sneaking suspicion that the code is selecting all rows with EventType=9 expecting there to be only one. A cursor is opened on this and then, instead of just using the first row found, it reads all of them. That would be OK if there was only one row, but when there are several thousand, it takes time.

The fix is to delete all the rows or delete al except one and change its ContentID to an empty string. And I suspect the firmware has already been fixed to prevent this incorrect row being created in the first place.