Forma Can Calibre autorecord Finished-read status and time spent reading (hours&minutes)?

[droopy]

1. How can I get Calibre to automatically record "Finished' status of a book that I've finished reading on my Forma?
2. How can I get Calibre to measure how many hours and minutes I've taken per book that I've read on my Kobo Forma, whether I'm still reading a book or whether I've completed it?

UPDATE:

I'd also like to have something else (and some of you have mentioned it):
3. the timestamps when I read each book.
For example,
Book_A
20200701 16:15 ⁠— 19:55;
20191224 23:24 ⁠— 20191225 00:01

Book_B
20200430 07:10 ⁠— 07:12

Book_C
20200430 06:40 — 07:05; 07:20 — 08:39

[PeterT]

Finished can be captured via the Kobo Utilities plugin

[davidfor]

As @PeterT said, my Kobo Utilities plugin can get the reading status of the book from the device. That includes the percent read and the last read timestamp. It doesn't get the time spent reading. That one I have to revisit as it is stored. But, there is an issue if you use multiple devices to read the same book.

[geek1011]

Originally Posted by davidfor

As @PeterT said, my Kobo Utilities plugin can get the reading status of the book from the device. That includes the percent read and the last read timestamp. It doesn't get the time spent reading. That one I have to revisit as it is stored. But, there is an issue if you use multiple devices to read the same book.

Since Calibre is written using Qt, it should be simple enough to decide the Qt QDataStream from the ExtraData blob (it's an encoded QMap<QString, QVariant>, and the format hasn't changed between versions of Qt and Nickel). The field you're looking for is ExtraDataReadingSeconds in the ExtraData for event 46 for the book.

~~Note that the last time I checked, PyQt didn't have full support for decoding encoded objects with type parameters. You may need to read the stream manually, but it isn't all that complex (and you can still use the read* functions on the PyQt datastream so you don't need to implement all of it from scratch). For reference, you might find my Go implementation of QDataStream useful (note that it implements a lot more than is needed for the ExtraData).~~ Update: see below

Update: I just checked PyQt, and it does actually support the required types for reading it directly. You'll need to initialize a QDataStream from a QByteArray of the ExtraData blob from event 46 in the DB, set the version to Qt 5.2, call readQVariantMap, get the ExtraDataReadingSeconds from the map, then call toInt on the QVariant to get the actual value as a usable number.

[davidfor]

Originally Posted by geek1011

Since Calibre is written using Qt, it should be simple enough to decide the Qt QDataStream from the ExtraData blob (it's an encoded QMap<QString, QVariant>, and the format hasn't changed between versions of Qt and Nickel). The field you're looking for is ExtraDataReadingSeconds in the ExtraData for event 46 for the book.

~~Note that the last time I checked, PyQt didn't have full support for decoding encoded objects with type parameters. You may need to read the stream manually, but it isn't all that complex (and you can still use the read* functions on the PyQt datastream so you don't need to implement all of it from scratch). For reference, you might find my Go implementation of QDataStream useful (note that it implements a lot more than is needed for the ExtraData).~~ Update: see below

Update: I just checked PyQt, and it does actually support the required types for reading it directly. You'll need to initialize a QDataStream from a QByteArray of the ExtraData blob from event 46 in the DB, set the version to Qt 5.2, call readQVariantMap, get the ExtraDataReadingSeconds from the map, then call toInt on the QVariant to get the actual value as a usable number.

Don't you think that that might be overkill when there is the column "TimeSpentReading" in the content table? That has been there for a while, I just haven't been that interested in fetching it. Then there is the issue of multiple devices.

But, I keep meaning to look at those. I just keep finding other things to do

[geek1011]

Originally Posted by davidfor

Don't you think that that might be overkill when there is the column "TimeSpentReading" in the content table? That has been there for a while, I just haven't been that interested in fetching it. Then there is the issue of multiple devices.

But, I keep meaning to look at those. I just keep finding other things to do

Oh, I wasn't aware of that column. The ExtraData was the first thing I thought of looking at since I was messing with that stuff recently anyways. It's also what the FW looks at to determine the total reading hours. On another note, since PyQt supports the required types natively, it would probably be at most 6-12 additional lines of code compared to looking at that column directly.

For multiple devices, I wonder how Nickel will react if the event row is duplicated. If that works fine, it would be possible to hack together a sync solution by adding a custom field to the ExtraData to keep track of which device each row came from (I won't go into details, but you won't run into issues with the checksum as long as the book is at the same path). Whether or not I'd recommend shipping this to ordinary users as part of the plugin is another question... Edit: I just realized that the checksum would fail with the EventData changes, but another idea would be to use the FirstOccurrence and LastOccurence dates (you can't change them, but they should be unique between devices). This also has the advantage of being slightly easier to handle. What I said about the book path and the checksum still stands, though.

[droopy]

Originally Posted by davidfor

As @PeterT said, my Kobo Utilities plugin can get the reading status of the book from the device. That includes the percent read and the last read timestamp. It doesn't get the time spent reading. That one I have to revisit as it is stored. But, there is an issue if you use multiple devices to read the same book.

Appreciate all the replies (PeterT, DavidFor, Geek1011).

I have just one device: a Kobo Forma. So thankfully I won't have this issue.

In my OP, I asked about:
1. Finished status
2. Time spent reading.

I'd also like to have something else (and some of you have mentioned it):
3. the timestamps when I read each book.
For example,
Book_A
20200701 16:15 ⁠— 19:55;
20191224 23:24 ⁠— 20191225 00:01

Book_B
20200430 07:10 ⁠— 07:12

Book_C
20200430 06:40 — 07:05; 07:20 — 08:39

[davidfor]

Originally Posted by droopy

Appreciate all the replies (PeterT, DavidFor, Geek1011).

I have just one device: a Kobo Forma. So thankfully I won't have this issue.

In my OP, I asked about:
1. Finished status
2. Time spent reading.

I'd also like to have something else (and some of you have mentioned it):
3. the timestamps when I read each book.
For example,
Book_A
20200701 16:15 ⁠— 19:55;
20191224 23:24 ⁠— 20191225 00:01

Book_B
20200430 07:10 ⁠— 07:12

Book_C
20200430 06:40 — 07:05; 07:20 — 08:39

Sorry, there is nothing I know of out there that does that. The Kobo Utilities plugin gets the last read timestamp, which is the time the device has recorded as when you last closed the book. While the device does record the reading session details, it is not as simple to get. The posts above from @geek1011 gives some details on why. But, there is no documentation on these values, so it could change (and has at least once). And there then there is the question of exactly how to store it so it is useful. And, personally, I have very little interest in it. I'd really only be doing it for curiosity about how the data is stored or as a coding exercise. If someone else wants to do it, I can look at including the code in the plugin.

[geek1011]

Originally Posted by davidfor

Sorry, there is nothing I know of out there that does that. The Kobo Utilities plugin gets the last read timestamp, which is the time the device has recorded as when you last closed the book. While the device does record the reading session details, it is not as simple to get. The posts above from @geek1011 gives some details on why. But, there is no documentation on these values, so it could change (and has at least once). And there then there is the question of exactly how to store it so it is useful. And, personally, I have very little interest in it. I'd really only be doing it for curiosity about how the data is stored or as a coding exercise. If someone else wants to do it, I can look at including the code in the plugin.

It is possible to get the timestamps. My QDataStream parser written in Go will handle the ExtraData for that event (I forgot which number, but it was the one with the largest ExtraData blob) correctly, including the timestamps. I do agree with @davidfor that this wouldn't really be useful in Calibre, though.

If anyone is interested in doing stuff with the ExtraData, I am willing to help, but only with the ExtraData stuff (I don't have experience with Calibre plugins, and I'm not planning on writing another entire tool as I already have too many [see my signature]).

[droopy]

Originally Posted by geek1011

It is possible to get the timestamps. My QDataStream parser written in Go will handle the ExtraData for that event (I forgot which number, but it was the one with the largest ExtraData blob) correctly, including the timestamps. I do agree with @davidfor that this wouldn't really be useful in Calibre, though.

Thanks for the follow-up, geek.

I can see how timestamp data may not be useful inside Calibre. I think it would be more useful in a spreadsheet. Thus, I'd be glad to see it in some format (like a CSV, I guess?) that a spreadsheet program like LibreOffice or Google Sheets can interpret.