Quote:
Originally Posted by grizedale
Slight misunderstanding, I did not mean directly on the device but through Calibre...
|
Ahhh, now I understand the question.
Yes, today the only way to change the collections (the metadata) is to resend the book.
Random musing follows:
Inferring from your question, what you want is to have the collections automatically updated when you change metadata in the library. I want the same thing, but have been struggling with the gotchas for some time. Putting aside the implementation complexities in calibre, I have been worried about the metadata in the cache (that .calibre.metadata file) differing from the metadata in the ebooks (epubs in particular). If the cache is ever rebuilt, the metadata will revert back to what is in the book. Resending the book avoids this problem, at least for epubs.
I have come to the conclusion that I can live with the cache differing from what is in the book. After all, it will always be true for formats that don't store metadata, and will sometimes be true if the cache was rebuilt.
This leaves me with the question: what do calibre users want? Would it be a good thing to automatically update metadata, or would people hate it (and hate my cat while they are at it)? My experience with the 0.7 beta implies that the only way to find out is to implement it, then wait for the kudos and rocks. Both will come.
Kovid and I are exploring this question. We have discussed providing a 'timestamp' for metadata, which would provide a way to detect that it has changed. If changed, then the new metadata would be sent back to the device during device/book matching. Another possibility: provide an option on the device menu directing calibre to update the metadata for all books on the device that are matched with a book in the library, or possibly a selection of books that are matched. The first would be automatic, the second would require user interaction. The first must wait for the metadata cache redesign required for custom fields, the second could be done now.
I lean slightly toward the second, because it permits people who don't want it not to use it. On the other hand, it raises the already-high learning bar just a little more. And yes, I anticipate the response "Do both and give me an option to choose which to use." The difficulty: adding options raises all of the learning bar, implementation complexity, and maintenance complexity. They shouldn't be added lightly.
And that is the state of the world...