[davidfor]

Originally Posted by eskwayrd

I had seen that before. It provides a workaround, which is not very tenable when you have tens of thousands of ebooks, and effectively says that discussing the design philosophies is off the table.

Yes, it is probably off the table. At least until someone comes along who:
- Can demonstrate they have made more than a cursory read of the previous discussions.
- Offers a good reason to change.
- Offers the resources to do it.

Personally, I haven't seen anyone come up with anything that comes close to a good reason. Are you offering the last?

The FAQ claims "By managing books in its own directory structure of Author -> Title -> Book files, calibre is able to achieve a high level of reliability and standardization."

The questions I have are:

* What reliability improvements have been achieved?

The less code you have, the more likely it is to be reliable. Having to add code to handle multiple directory structures increases the complexity and hence increases the likelihood of a problem.

And if the books are in locations that calibre doesn't control, it is far more likely something will get deleted or moved and the linkage to the books is lost. And we have more code to manage this.

* How were those measured?
* What standardization is Calibre attempting to meet?

Using a consistent standard across multiple OSes and installations means that moving from one to another is easy. Plus support is easy - "Look in X" rather than "work out what X is then look there".

Without know the answers to those questions, it is hard to determine whether Calibre is undertaking too much work during certain kinds of metadata updates. It certainly feels slower than I'd expect.

For example, renaming an author often takes 8-12 seconds to complete per ebook. I store my photos on the same volume, and updating an IPTC field with LightRoom takes less than a second.

I can't comment on performance because I don't really notice it. Whether that is because my library is small enough not to cause problems or the PC fast enough, I don't know. It just works and I don't have to wait to long (except when I am in a hurry and then it is always to long).

I don't disagree; a GUI for bulk management is easier. Even for single entry updates, the Calibre GUI is much easier than unpacking an ebook's contents, making the desired change, and repacking the ebook.

It's the directory management effort that I'm unsure about.

That wasn't my point. By using a single known naming standard for the file structure, I am sure it makes the code in calibre a lot simpler. That's for the book management. The editor or viewer accepts a path to the book and opens it.

From my point of view, once I accepted that using a GUI for the book management was better, I completely forgot about the file structure. As far as I'm concerned, it is a database managed by the application. I went through this for my music. I had a complicated structure, then started using MediaMonkey. That does allow "inplace" adding, but it is much easier for me to let if collect the media files and organise it how it wants to.