Alternatives to Calibre?

[EowynCarter]

That post was made in response to a constant flood of threads like this one. There was a flood of people demanding to be able to change the file system and ranting about how terrible Calibre is for not allowing it that it was becoming a headache for the moderators here to foster any discussion on any other topics. The response was the deletion of those threads, a number of bans and finally that post being stickied.
It's not a Calibre Dev issue, it's a forum moderation issue.

True. But a post explaining the technical reasons behind the choices, the "it takes time and we don't have this time", would probably be better received, and might avoid people venting their frustration by opening an other topic anyway.

And also the "tips" to go around the problem too.

[DoctorOhh]

Originally Posted by EowynCarter

But a post explaining the technical reasons behind the choices, the "it takes time and we don't have this time", would probably be better received, and might avoid people venting their frustration by opening an other topic anyway.

And also the "tips" to go around the problem too.

I find the post fine, but the post might be due for an update. If you have the time maybe you could give it a go.

[BetterRed]

Originally Posted by Adoby

Hypothetically, if calibre didn't have the current internal folder structure, how should it work? I can see a lot of problems connecting metadata to the actual books, and allow changes to the library structure. Or handling deleted, duplicated and added books.

One could maintain references to user managed folders in the database, and install a daemon/service that monitors the file system and acts on folder renames/moves/deletes etc to keep the database aligned with the file system.

But this one wouldn't...

BR

[speakingtohe]

Originally Posted by EowynCarter

The biggest obstacle is the "No way" attitude everytime someone dare mention this... There is a topic that actually say "don't speak about it".
https://www.mobileread.com/forums/sho...d.php?t=119175

It's a shame to bury the problem, go for the "deal with it" attitude, instead of trying to fix things.

While I agree it is totally up to the developers what file system they use, I also think you are right about the way that people seem to pounce on those who would have it otherwise.

I have no problem with the file structure, and in fact find it less annoying than the Windows way of doing things. Still every time I see someone typing don't look under the skirts or think of it like a black box, I think gag me with a spoon
And the thread you point to starts off pretty rude really when you think of it. Not meant that way I am sure, but you are right to feel a bit miffed by it's stern grandfatherly tone.

I wish you luck with your project and would be interested in looking at it when you are at a stage that you are thinking of distributing it, but I think calibre is a hard program to beat. Sure it could be better, just like most things, but IMO it is pretty darn good as is.

Helen

[HFC3]

This has probably been mentioned in an earlier post, but my problem with the original post wasn't that he/she was looking for a Calibre alternative. More power to him. It was the tone of the post itself.

Anyone is welcome to use another tool, or build one of their own if they want/can, but bashing the authors and contributors while asking isn't the best way to Win Friends and Influence People.

"Monopoly" - Calibre doesn't have a monopoly. No-one else has written anything close to accomplishing what Calibre does. How can it t be a monopoly if it's the only product of it's kind available?

"bugger off" - Nothing I've seen in the threads has ever said "bugger off", or translation of same. People have asked why, others have explained. Some have asked can we ..., and others have explained why, why not, or gee, that's a great idea!

From what I can see his complaint is that Calibre won't talk to his Android, or won't transfer data to his Android the way he wants it to. Maybe the title should have been "How do I get Calibre to work with my Android?"

I don't see anything in his post that actually defines this mysterious "STRUCTURE" he demands, or what's he's done using Calibre's plethora of transfer features in an attempt to accomplish this.

Plus, his use of "magical" seems illustrates that he doesn't understand (possible not even researched) that Calibre is designed to facilitate "converting" it's base structure during transfer to a device's. Isn't that what he wanted? It took my 5 or 6 hours, but I got Calibre to not only change how it arranged the data on my (admittedly) Kindle, but to change (well, 90%) the titles and file names of the books.

Actually, as a programmer (past) myself, and as DedTV said, the physical filenames used by a program are rarely important to anyone other than the program itself. Ultimately, it's how the program itself takes the information and presents it through the GUI that matters.

So, why does it matter how Kovid and other contributors arrange the files on the PC (MAC)? They've provided facilities inside Calibre that (as I said above) actually let you change that information during the transfer to the device. That's an incredible factor in the flexibility of Calibre itself

Finally, I see that there is an Android plug-in. So, what's the real problem here?
1. Didn't look for Android plug in. It it's not doing what he wants, why?
2. Didn't (want to) learn how to use Templates to change the file structure during transfer to device
3. Didn't (want to) learn Plugboards to change eBook metadata on transfer?
4. Was primarily interested in causing trouble?

Hmmm.

[Kirtai]

Originally Posted by BetterRed

Whereas the music collection organisers I know of only do the metadata part, and you have to figure out and maintain a storage solution.

On a somewhat unrelated note, MusicBee can automatically move and rename music files for you using a metadata template.

[K. Molen]

Here's a question, asked out of curiosity:

Would it be possible for a program like Calibre to simply leave the book files wherever they are upon import? Meaning, if a book is sitting on my desktop when I import it, the file is left there and the database points to it there. If the next book I import is sitting in My Documents, the same thing happens.

So, if you're not careful, you might have a database pointing to book files littered throughout the hard drive. But if you're careful, you could then have your own directory structure, with Calibre pointing to each book wherever you put it.

Even if this is possible, I completely understand that it's probably a decision that would've had to be made very early in the development cycle, and that it'd be a huge undertaking to change it now. I'm not suggesting such a change be made.

But what I'm wondering is, if this is possible, why was the decision made to handle files the way they are currently handled? Was it just to protect users who may not be aware of where they're storing their files? Or is there perhaps a more technical reason involving response times or something else?

[itimpi]

I am not sure if the original decision was made to speficially exclude a pointer based system, or it just happened in the evolution of Calibre. However it is now an embedded asumption and thus hard to change.

Reasons I can think of off-hand include:

• If links get broken then you get serious problems with the base Calibre dataconsitency. It is too easy to do this if files are stored outside Calibre control.
• The databse recovery capability would not be possible if Calibre did not know where to find the metadata.opf files stored with each ebook
• Any solution has to be portable across all supported OS (Windows, MacOS, Linux)

I am sure there are many others.

All the main Calibre functionality is exposed via the Calibre CLI so it might be possible for a really interested developer to do something without having to re-invent all the capability.

[DoctorOhh]

Originally Posted by K. Molen

But what I'm wondering is, if this is possible

Yes it is possible.

Originally Posted by K. Molen

Was it just to protect users who may not be aware of where they're storing their files? Or is there perhaps a more technical reason involving response times or something else?

It was done as much to protect users from themselves as it was to protect the developers from fielding massive questions about disappearing books. Essentially it was a quality control measure forcing books into one location. This limited folks from moving things around or deleting them without realizing that it affected their library.

[K. Molen]

Originally Posted by itimpi

I am not sure if the original decision was made to speficially exclude a pointer based system...

Reasons I can think of off-hand include...

Originally Posted by DoctorOhh

Yes it is possible.

It was done as much to protect users from themselves as it was to protect the developers from fielding massive questions about disappearing books. Essentially it was a quality control measure forcing books into one location. This limited folks from moving things around or deleting them without realizing that it affected their library.

Thank you both for responding. I can certainly understand the logic behind doing what was done. I for one wish that optional manual storage management had been included as an advanced option during install, but I obviously understand why it won't ever be.

Thanks again for responding.

[itimpi]

Originally Posted by K. Molen

Thank you both for responding. I can certainly understand the logic behind doing what was done. I for one wish that optional manual storage management had been included as an advanced option during install, but I obviously understand why it won't ever be.

I am not sure that it will NEVER appear! Just that it is unlikely to happen any time soon.

There has been a long-running project to change the way that Calibre interfaces to its database and underlying file store to support multi-user working. Even this change which on the face of it sounds relatively easy is proving non-trivial. I believe that Kovid has been working on this part time for a year or two already. The problem is how to evolve towards the target change without breaking everything and also keeping performance acceptable. With there already being millions of users of Calibre then this is important. Also the weekly release schedule underlying the Calibre development methodology means a process of small incremental changes is desirable.

[BearMountainBooks]

There are no alternatives that come anywhere close to the functionality. In general, there are no other options at all really.

[fidvo]

Originally Posted by speakingtohe

While I agree it is totally up to the developers what file system they use, I also think you are right about the way that people seem to pounce on those who would have it otherwise.

To be fair, the tone of the original post in this thread was openly hostile. Is it any wonder that the responses are less than friendly?

Originally Posted by speakingtohe

I have no problem with the file structure, and in fact find it less annoying than the Windows way of doing things. Still every time I see someone typing don't look under the skirts or think of it like a black box, I think gag me with a spoon

But that's the correct answer to the question. The answer doesn't change no matter how many times the question gets asked.

Originally Posted by speakingtohe

And the thread you point to starts off pretty rude really when you think of it. Not meant that way I am sure, but you are right to feel a bit miffed by it's stern grandfatherly tone.

I don't see it as particularly rude; it's just concise. There's no "We're sorry that the database structure doesn't conform to the way you would like to do things..." It just tells it like it is.

Originally Posted by speakingtohe

I wish you luck with your project and would be interested in looking at it when you are at a stage that you are thinking of distributing it, but I think calibre is a hard program to beat. Sure it could be better, just like most things, but IMO it is pretty darn good as is.

Helen

I'm also curious about EowynCarter's project, specifically how he addressed the issues mentioned by itimpi:

Originally Posted by itimpi

Reasons I can think of off-hand include:

• If links get broken then you get serious problems with the base Calibre dataconsitency. It is too easy to do this if files are stored outside Calibre control.
• The databse recovery capability would not be possible if Calibre did not know where to find the metadata.opf files stored with each ebook
• Any solution has to be portable across all supported OS (Windows, MacOS, Linux)

EowynCarter must have come up against these exact same issues, and found some way to deal with them. Synchronization between the database and the files is the single biggest reason why Calibre adopted a "hands-off" policy, so if EowynCarter's program finds a solution to this, I'm very interested in knowing how.

[speakingtohe]

Originally Posted by K. Molen

Here's a question, asked out of curiosity:

Would it be possible for a program like Calibre to simply leave the book files wherever they are upon import? Meaning, if a book is sitting on my desktop when I import it, the file is left there and the database points to it there. If the next book I import is sitting in My Documents, the same thing happens.

So, if you're not careful, you might have a database pointing to book files littered throughout the hard drive. But if you're careful, you could then have your own directory structure, with Calibre pointing to each book wherever you put it.

Even if this is possible, I completely understand that it's probably a decision that would've had to be made very early in the development cycle, and that it'd be a huge undertaking to change it now. I'm not suggesting such a change be made.

But what I'm wondering is, if this is possible, why was the decision made to handle files the way they are currently handled? Was it just to protect users who may not be aware of where they're storing their files? Or is there perhaps a more technical reason involving response times or something else?

Anything is possible some say

One potential problem is that if a user buys books from several sources/stores, the kindle books would be in the kindle directory, Sony in the Sony directory. Calibre could be happily pointing away at these books and the directory could be renamed for some reason. Or a drive added/removed could change the drive letter of one or more, then the user must track down the books and do whatever is required show calibre where they are.

Or if a user bought a new computer there could be multiple directories to copy and if on different drives, paths to be resolved.

I know there are probably programs that automatically handle these things, but it would add a lot more to the task. And even if calibre could copy/move all files as they were in their different little directories to a different computer, would I really want this? Doubtful in my case.

I like that the books are all in one large directory, the fact that they are all grouped under author>title, and for the most part I like that all files are individually useable. There have been the odd times I wish it was a little different, but these are very rare. (usually when I am backing up I curse the fact that there are so many small files, but this is more a Windows file copy slowness problem).

Probably not impossible to change, but maybe impossible to change in a way that would make everybody happy.

I imagine, perhaps wrongly, that if the file system was radically changed at this point there would be a great wailing and gnashing of teeth form the countless number of people like myself who are happy with the way things are now.

Helen

[EowynCarter]

Originally Posted by fidvo

To be fair, the tone of the original post in this thread was openly hostile. Is it any wonder that the responses are less than friendly?



But that's the correct answer to the question. The answer doesn't change no matter how many times the question gets asked.



I don't see it as particularly rude; it's just concise. There's no "We're sorry that the database structure doesn't conform to the way you would like to do things..." It just tells it like it is.



I'm also curious about EowynCarter's project, specifically how he addressed the issues mentioned by itimpi:



EowynCarter must have come up against these exact same issues, and found some way to deal with them. Synchronization between the database and the files is the single biggest reason why Calibre adopted a "hands-off" policy, so if EowynCarter's program finds a solution to this, I'm very interested in knowing how.

Well, touching the files outside the program is still no go. But it's read only i'm interested in.
I have some resync, clean database, then goes through all the folder to rebuild it.
Java have some feature to watch for filesystem changes. In my case, it's a webserver, so could probably do.
What can be done is to have the database store the date the file was last edited, so as to detect conflict.
Then you have to goes though two loops to detect stuff in database no
longer in filesystem and vice-vera.