Calibre Library Management Whitepaper?

[eskwayrd]

I've searched and read many discussions, but I haven't found a single, concise reference for why Calibre maintains its ebook library content the way it does. Specifically, why Calibre feels the need to make/maintain the author/title/ebook directory structure.

I have found plenty of discussions that suggest "Calibre knows how to organize ebooks better than you", none of which provide any evidence to back up that kind of claim.

I've skimmed through the Calibre source, and the directory structure assumptions appear in many places, so I can see that it would be some effort to effect any change in the approach.

Thanks for any pointers!

[davidfor]

How about Want to change folder structure or file names in the Calibre library?

And my take has always been that it is a lot easier for calibre to do it this way.

[eskwayrd]

Originally Posted by davidfor

How about Want to change folder structure or file names in the Calibre library?

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.

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?
* How were those measured?
* What standardization is Calibre attempting to meet?

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.

Originally Posted by davidfor

And my take has always been that it is a lot easier for calibre to do it this way.

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.

[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.

[BetterRed]

Moderator Notice
I moved this out of the Development subforum. To understand why, see the sticky thread PLEASE READ BEFORE POSTING - Purpose of Development subforum at the top of that subforum.

...not the place to reopen fundamental calibre design decisions, in particular the calibre library file system...

BR