Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ghappe-MC]

I've a Small comment on build 26.0.84 (5/22/2020) and I'm not sure where to put it?)


4. NEW: Sidecar files of the type OPF are loaded for EPUB books (the sidecar must be the same name as the book in the file system other than the extension).

This is fantastic, however, most OPF files, created by other applications don't have the same name as the e-book, so i suggest, if it's the only OPF file in the folder to load it anyway regardless of the filename.

Guido

[Matt]

Good idea.

Coming next build:
NEW: Sidecars for epub books will look for any OPF in the same folder instead of only the same filename.

If it finds a single OPF file in the same folder, it will be used.

[ghappe-MC]

Hello Matt,

I sincerely hope your day is covered in sunshine, must be so because we are presently getting all the rain.

So, I've spend some time thinking about the epub etc. subject and i came up with some views and the feeling that it could be either simple or complex.

Since it does indeed interests me i put my brainwaves tot paper and hope it is not regarded as "unsolicited", however, you can press delete now or read on at your own risk.


First of all I do consider the audience, who will be making good use of any epub implementation in MC?

Now I do share and swap books with a lot of friends and 99.79 % of them is presently using Calibre and, just like me, do so with mixed feelings. (It's very slow, has an outdated interface and poor support for bulk edits.

Anyway, when using (migrating) Calibre epub's it's good to realize the following.

When, as far as I know, an epub is read by, and added to, Calibre it is saved in the Calibre home folder and the naming convention is fixed and therefore poorly set for the use by other applications.

Then the metadata, witch is by choice extracted from the embedded metadata in the epub file or from the filename, and then saved in a SQLite database.

Furthermore an OPF  file is created containing the metadata which is saved next tot the epub file with possible companionship of a JPG file holding the book cover.

So far no sweat!, but when you update a tag in the Calibre program that does instantly update the OPF file and the SQLite database BUT NOT THE EMBEDDED METADATA in the epub file.

Therefore there is a potential difference between de data in the OPF and the epub.

There are, of course, ways of updating the metadata in the epub but they are cumbersome at best. (As save all data to disk in an other folder, empty the library en reload al the data)

Calibre says this is done for performance reasons because updating the embedded metadata in the epub file requires (in most cases) the expanding and re-compressing of the file and that does indeed take time, however, a lot of processing power has been added to our now-days computers since this design decision was made.

So, if we, (The users) would import epub files, coming from Calibre, without additional actions into MC we must make sure the embedded metadata is up to date.

And doing just that would be the simplest way of getting things done, only read the epub file, extract the metadata into a number of designated tags in the MC library and when making changes to the tags in the MC library and (depending on the setting of " update the file if data is changed" in MC, also update the embedded metadata in the epub file.

If those epub files would be handled in MC in the same way as MP3 files you would facilitate basic functionality for e-reading in MC without a lot of development.

There can, of course, be a more elaborated, and therefore very complex, way of reading both the epub and the OPF file and determining what data to save in MC but that would require a lot of branching in the program (for example, What if there are more than one epub and/or one OPF file in the folder? something that can not occur in Calibre because of the strict conventions but it could well be in MC where we enjoy the freedom to place our files wherever we want)

JRiver, being a commercial enterprise could and should ask itself if  the users would be willing to pay for these extra lines of code and after talking to some friends I would think not so. Calibre, with all the pro's and con's is freeware and for most people money still counts.

So, my unsolicited advice would be, go for a simple solution in the firs place and see (on the forum) what use it gets, you can always expand things if there's enough popular demand.

Therefor, hoping that my intentions are not misunderstood, I remain, by wishing everyone over there a nice weekend and a perfect health.

Greetings,

Guido