@dwanthny & @Starson17: Thanks for the kind words. They are appreciated.
It isn't pleasant to get problem reports expressed in angry verbiage. I am not sure why, because none of the posts have been ad hominem, the design predates my time, and I can understand where the anger comes from. One must also recognize that 'finding' the problem wasn't pleasant for the reporter. In the end, getting reports, however they are expressed, is a precondition for dealing with them, so the value of (gain - frustration) is positive.
It is unfortunate, though, that some of the reporters suffered from problems that were already fixed.
@starson17:
Quote:
|
A related question: I could have sworn that for the Sony, Calibre has created collections from tags from day 1. Isn't that why most Sony users turn off the tags? If so, why is it that this is suddenly a problem for some users?
|
The answer must be related to scale. In 0.7 before 0.7.6, calibre would recreate requested collections for books already on the device. Instead of finding him/herself with a lot of extra collections on one newly-sent book, they would be on all the books on the device. In 0.6 and before, people must have dealt with it by changing collections for the books they just sent. 0.7's insistence on following directions came as a rude and unwelcome surprise.
One reason I didn't anticipate the problems is my own usage pattern. From my beginning with calibre, I managed tags etc so that the Sony DB was automatically built as I wanted. In fact, I wanted (and still want) calibre to be *more* aggressive, rebuilding the Sony DB from metadata whenever I connect, without me needing to send any books. I am still trying to work out how to do that while maintaining the status quo for the manual types. I am considering making the new collections option tri-valued, where the third value tells calibre to manage upon connection.
Enough rumination.
