Calibre - An excellent program, but no thanks

[tompe]

Originally Posted by ilovejedd

Nope. You'll just have to provide bugfixes and support for your changes:

But the common thing is to have a developer and a user community for a successful open source project so the support is distributed. Normally the ordinary users can handle the support on the user mailing list.

[kovidgoyal]

I should say that calibre has a very active development community, with lots of contributions from third party developers. As well as a very active user community as evidenced by these forums. I don't develop calibre for the money, though donations do allow me to spend a larger fraction of my time on it.

For an incomplete list of the contributions to calibre, see http://calibre.kovidgoyal.net/wiki/D...t#Contributors

Also I note that for calibre 0.7, calibre will become database backend independent and plugin based. At that time it will be considerably easier to implement this (and a lot of more important) features. I'm not saying I will implement it then, but it should become trivially easy for some one who wants to, to write a plugin.

EDIT: Also for a good feel of how much of calibre's functionality has been coded by people other than me, just look at Preferences->Plugins to see how many people have contributed plugins. Also I think about 70% of calibre's recipes have been contributed by users.

[kovidgoyal]

Originally Posted by tompe

Maybe the problem is that the project is associated with just one person. It might be hard to get more developers. And the request for donations does not help in getting more developers for what it says is "this is my project" and does not really stimulate other people to participate.

Like the linux kernel?

[corroonb]

Was calibre originally intended to be anything more than an ebook library management tool? Did the conversion tools come later?

I think people should realise that calibre, as good as it is, cannot be all things to all people. Even attempting to satisfy all potential users is probably not a sensible design decision (not that I think kovid is trying to do that). I would even argue that too many formats are supported for conversion. Are there any plans to remove formats that are effectively dying out like LIT, PDB, LRF?

[kovidgoyal]

Brief history of calibre:

1) Reverse engineer the SONY PRS 500 as it could not then be used on anythong except windows and with anything except the craptacular SONY software

2) release as libprs500, a library to interface with the PRS 500

3) Write html2lrf as a platform independent way to create LRF files. At the time there were probably a total of 100k LRF files in the world.

4) Write a GUI to manage ebook collections and interface with SONY readers.

...

Having support for additional formats doesn't hurt and since I don't maintain them (they're maintained mostly by user_none) I'm happy to leave them in

[corroonb]

Thanks for explaining that.

Would a stripped down version of calibre which could only convert to one format (chosen at installation) be less resource intensive? Could this be done with some sort of plug-in system (just for more advanced users)?

I have very little programming experience so apologies if these questions are stupid.

[kovidgoyal]

Not really, the conversion subsystem is plugin based and is only loaded in separate processes.

[user_none]

Originally Posted by tompe

Maybe the problem is that the project is associated with just one person. It might be hard to get more developers. And the request for donations does not help in getting more developers for what it says is "this is my project" and does not really stimulate other people to participate.

I suggest you look at http://calibre.kovidgoyal.net/wiki/D...ofcodebugfixes and https://launchpad.net/calibre/+topcontributors There is between 20 - 25 people (that I know of) who do and have contributed to the project with code and translations. There are probably more because those lists don't include emails to Kovid directly, submissions to the ticket system or the one time small patch from someone.

[pshrynk]

Originally Posted by kovidgoyal

Just visit the calibre bug tracker to see how many open feature requests there are.

More people request conversion to/from LRF in a month (a dying format that has been abandoned by its only corporate sponsor) than the total number of requests I've seen for this feature.

Speaking of which...

[bkilian]

Originally Posted by kovidgoyal

calibre does not compress files, it does not store all books in one file, it is perfectly possible to do differential backups with calibre's library (I do it all the time). You can change where calibre stores its books, in fact you can have multiple libraries at different locations. You can run calibre entirely off a USB key if you want to.

The OP really should ask about things before making assumptions and then complaining.

And I defy anyone to give me a single use case where having calibre support their pet folder structure is better.

Calibre making a copy of my files, and then not even keeping those files current until I "save them out" is the #1 reason I don't use the GUI portion of the program at all. (#2 is the terrible performance, but that's not Calibre's fault, it's the fault of the UI libraries it uses)

The way I maintain my books is that I have a "source" directory structure with all my source ebooks. When I get a new book, I add it to the source folder and then run a script to generate the LRF and Kindle versions. My LRF and Kindle directories are synchronised the the other PCs I use and the other PCs in my household. If there is a metadata issue, I edit it directly in the source file and regenerate the terminal formats. Same for fixing book content (I'm amazed at the errors publishers will tolerate in their ebooks).

I do most of my ebook management from the command line and I often will edit a book and format shift it to epub for permanent storage (well, I _was_ doing that when Calibre used ePub as it's "internal" format, but now I may have to go for OEB of some sort. Kovid, is there a format I can use which will result in minimal processing on the input plugin? Preferably one that Calibre can output as a single file.)

There is just no way using the Calibre GUI would work for my use case. I rely on the specific directory structure I created too much. With the Sony software, I just rescan the LRF directory, and it updates the changed files, which is still worse than I'd prefer, but I learned a long time ago that I'm not an "apple" person. (iTunes is possibly the worst designed piece of crap I've ever had the misfortune of being forced to use IMO, and I hate that all these other "media management" programs try to ape it's behaviours)

I don't see any reason why Calibre's copy-til-you-drop philosophy is better than the Sony software's usage of full filepaths, and a lot of reasons, in my case, at least, why it's a lot worse.

Originally Posted by corroonb

Thanks for explaining that.

Would a stripped down version of calibre which could only convert to one format (chosen at installation) be less resource intensive? Could this be done with some sort of plug-in system (just for more advanced users)?

I have very little programming experience so apologies if these questions are stupid.

No, what would improve the speed and resource usage of Calibre would be writing it in a language other than Python. I doubt that will happen. (I've got nothing against Python and QT, but they certainly can't be called zippy compared to native.)

[QuietSIlence]

first off this program is excellent for converting to and from diff formats all though its vary slow at it it does a good job although why it doesn't do TO html is a wonder

butt:
Why doesn’t calibre let me store books in my own directory structure?

The whole point of calibre‘s library management features is that they provide an interface for locating books that is much more efficient than any possible directory scheme you could come up with for your collection. Indeed, once you become comfortable using calibre‘s interface to find, sort and browse your collection, you wont ever feel the need to hunt through the files on your disk to find a book again. 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 directory structure it uses is worse then useless and dangerous as it removes info from the file name

i dont understand why it has to rename the files at all
ie it made \QuietSilence\Desktop\Smith, E E Doc - Lensman 01 - Triplanetary (2.1) [html,gif]\
to
\QuietSilence\My Documents\calibre\E. E. 'Doc' Smith\Triplanetary (6)\Triplanetary - E. E. 'Doc' Smith.zip

and totally lost the series info in the file name as well as the version info (thats the (v2.1) part for those of you who dont know it)
not to mention it made title first then author and put last name last instead of first for the actual file name

what is the point of having a title dir ? the title is all ready in the file name.
i can see some peps wanting a author dir but i prefer just having dirs for each letter of the alphabet of the author name
ie D:\My Books\S\Smith, E E Doc - Lensman 01 - Triplanetary (2.1) [html,gif].rar (BTW the files in side of this rar are a dir called files full of js style.css and some gifs of arrows for navigation of the html and in root the html and the cover a gif in this case)

though i can live with author name instead its seems to be a wast of dirs

also it killed all js in the html and what is the deal with the (6) added to title dir?

i can live with the dir structure it self if i have too though i don't want to but renaming the file name it self is going too far

and there is a reason for the standard file naming convention that has been out for at least 10 years now and i know this because i am part of the group that came up with it. there is a lot of consideration gone in to it not limited to but including geting ebooks to sort properly, letting you know how much proofing has gone in to it (the vertion #) , and letting you know what format the file is in with out opening the rar now i not saying it has to be exactly like the standard. we built user preferences in to it ie you can use ether last name first or first name first but the info and the order that it is in the file name is important
i see you do use the standard space-space to separate the author a title why not use the rest of the standard?

ya ya i know it dosnt mess up the original file but who wants to maintain 2 dir structures for there ebooks ?

as it is now its a useless dir structure which makes it a bad ebook manager

the point of a good ebook manager is to let the user decide on the dir and file naming conventions that they need

to recant its a great format converter though a bit slow it does a great job much better then most format converters

but its not up to snuff yet as a ebook manager

please don't take this as a flame as it is not interned to be i use it all the time i just want it to be better as a manager and i am sure it can be

thanx to the coder for a excellent format converter

ps ill post the standard ebook nameing format in next post for any who are interested also a link to a app to help rename according to the standard format

[QuietSIlence]

FileNamingConventions(v1.0).zip
the convention

A file naming convention is a way to distinguish your e-books and monitor what e-books you have by making it easier to sort them in lists of files. It is rational to adopt a standard even if only leeching.

E-books come from many sources and everybody has their own preferences, so there will never be a single naming convention. However, we can agree on some good practice. We will use our own standard, to help demonstrate good practice.


http://iterati.org/ebookTools/BookSorter/Default.aspx
the app


Here are some key features of "BookSorter":

* .NET2 compliant.
* First name first (FNF) and last name first (LNF) for authors.
* Copy, move or simply rename the files.
* Multiple input directories and primary output. Option to copy to secondary directories with specified options.
* Author auto-correction (through a db with more than 5K entries).
* Sub-directories: first letter, author, genres, series.
* Prefixes/suffixes for series, title, version, type… like (v1.0).
* Uppercase, Lowercase, Title Case as well as the first letter uppercase for author, title and series.
* Pre-substitutions: define what to change/remove BEFORE processing. Example, remove "(Ellora)".
* Search inside rar/zip archives in order to determine the book type(s).
* Spaces or underscores. It replaces double spaces with singe as well.
* Visuals: several themes.
* Logs operations into a db.
* Choose fonts for various parts of the GUI.

this is not a ebook manager as such its a way to rename and organize your ebooks through a dir structure

[QuietSIlence]

remove this reply
sry i clicked the wrong thing

[macr0t0r]

Alright...how about a middle ground?
Would an export to a directory of links be sufficient? So, there would be the usual calibre folder structure that holds all of the files, but then there would be another folder structure of your specification that would contain LINKS to all of those files. Since it would only contain directories of links, it should be reasonably quick to generate, and maybe there could be a setting to update that structure whenever you close Calibre (and perhaps provide a CLI command to allow some scheduling).

This way, the original Calibre folder structure does not get mangled by the user (and causing a whole host of potential bugs and pitfalls), but you'd still have a folder with all of your content organized your way without the cost of additional hard-drive space (is that really a concern these days?).

He already has all of the hooks in the source code. Just create a python script that accepts your desired parameters and send it in to him. Perhaps some of you could attach some starter code to get the ball rolling.

I'm all for a little constructive criticism, but you guys are getting a little heavy on the developer here. He's trying to add features without breaking stuff, and your original request has a lot of potential to create some pretty mysterious issues. An exported link structure will probably be the safest way to do this.

- Jim

[QuietSIlence]

Originally Posted by macr0t0r

I'm all for a little constructive criticism, but you guys are getting a little heavy on the developer here. He's trying to add features without breaking stuff, and your original request has a lot of potential to create some pretty mysterious issues. An exported link structure will probably be the safest way to do this.

- Jim

hope I'm not taken as being heavy i was just trying to explain the reasons to use the standard naming convention

i think the coder has done a great job so far he seems to be an intelligent man just hasn't really considered the dir structure of his app yet which is understandable as he is prob more focused on the conversion then the naming and is after all sort of secondary too the conversion and moveing to the device