Quote:
Originally Posted by slantybard
chaley - I was curious if you can comment on the philosophy behind changing how calibre handles metadata and the devices? Ie, why change from 0.6 series method and the new 0.7 series method. Thanks for any info.
|
Are you asking why we made the change?
First, note that what I say below are my thoughts. Kovid could easily have a different rationale or longer-term reasons for why he started this work.
Calibre wants to know several bits of information about the books stored on a device. The obvious are correct title and authors, but having series, tags, dates, and some other information is also very helpful. The vast majority of devices do not store this information in a way that Calibre can see, and storing the information in file path names can go only so far. Because of this, calibre before 0.7 was severely limited in what it could do with the books. For example, using 0.6, the on device feature would have been very difficult, and perhaps impossible, to get close to right while providing even marginally acceptable performance. Detecting changes in collection information (and subsequent rebuilding) would have been impossible.
The goal was to store enough calibre metadata on the device to overcome these problems and to pave the way to future features, such as syncing. We are most of the way there. What is missing is the custom field information, which will be added in a few releases once we get time to finish the work.
Sony devices do store metadata, and are the only calibre-supported devices to do so, modulo the iPad, which I know little about. The issue we have been facing, as evidenced by this thread, is caused by Sony not publishing their database semantics. We must find what the information really means and how it changes by experimentation and reverse engineering, and in the process made some mistakes that hurt performance and correctness. For example, some things we have found are that the Sony truncates authors back to the first one when it rebuilds metadata, that it uses the local time of the PC instead of GMT when checking timestamps, and that it fabricates metadata for formats that can't have it (such as txt) or don't have it even though they can. We tested on our personal devices, but we clearly did not encounter all the corner cases. Thanks to the help of people on this forum, we think that the 0.7.2 release will have it right.
Did I answer your question?