Quote:
Originally Posted by BetterRed
I have a vague memory of someone telling me that the reason the built-in last_modified date exists and behaves as it does is/was related to synchronising the metadata in a calibre library with the metadata on devices.
BR
|
Quote:
Originally Posted by davidfor
I don't know of any devices that do that. But, it wouldn't be unreasonable to.
|
The topic has drifted a bit.
Calibre companion did that, at least back when I was writing it. If the last_modified date on a book was newer than the last_modified date stored in CC's database then several things happened:
- The metadata was queued for download or upload.
- The download cache was updated.
- If the upload-able fields (Read and Read Date) were changed since the last connection then the driver and CC decided which one wins.
Because of these checks CC could determine what books to sync by sending a few bytes from CC to calibre: the book_id and the modified date. Calibre would respond with either a request to upload the metadata (books on the device it hasn't seen before that require matching) or sending the metadata to CC.
It wouldn't surprise me if Koreader does it as well, given that it can use the wireless device protocol.
Changes to formats could also be synced, using the formats' modtime value to decide whether to resend it.