Modified Date on Titles.

[BetterRed]

Originally Posted by davidfor

I have never looked for the last modified date in the OPF. And with the way calibre handles it, it would make no sense. If you needed to use these to rebuild your library, the last modified date would be set to the current time. Or when the book was added to the rebuild library.

But, that wasn't really what I was meaning. Triggering writing of the OPF is done when the metadata is change. The data gets marked as "dirty", the modified time is updated and then the book is put into the queue for the backup. If you do a lot of changes quickly, such as changing a common tag, you can see the the last thing happening in the "Library metadata backup status" under "Library Maintenance". That shows how many are to be written.

- Ah-ha, now I remember, writing the OPF is 'triggered' by the existence of a book id in the metadata_dirtied table. Normally it's empty, but if you change a lot of books (e.g. by deleting an overused tag) and close calibre, you can see the outstanding book ids in that table, the calibredb backup_metadata command will 'process' them quickly, where 'process' is write the OPF and delete the entry from the metadata_dirtied table.

Which doesn't explain the purpose of the last_modified column… not to me at least.

BR

[chaley]

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

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.

[Quoth]

I use sort by the Last Modified column to see which books I've added OR done some work on that may or may not be on the eReader or might not have been updated on the eReader. The Date Added isn't so useful unless I've added duplicates and want to know which are older/newer.

I usually edit the Published Date column to be when the book was first ever published, or if edition is important, the edition's publish date, not the Amazon most Recent Publish/Print date nor Gutenberg's "Publish" date which is their date, not the actual paper edition date)