After running Modify ePub to update metadata (including cover) I get a metadata section that includes the dc: metadata and the following non dc: metadata: title sort, Series, series index, rating, user_categories, calibre:author_link_map and all of the junk that comprises all of my custom columns metadata. All of which is non dc metadata. The only thing I did not expect was user_categories, calibre:author_link_map and all of the junk that comprised my custom columns.

If I do an ePub to ePub conversion along with the dc: metadta calibre adds some non dc: metadata: title sort, series, series index, rating, calibre:timestamp and cover, but not all of the custom column junk. The result after a conversion is what I expected this plugin to insert as metadata.

I'm not saying this is wrong, but currently if you want only updated non dc: metadata you have to use two steps.

1. Run Modify ePub to Update metadata (including cover)
2. Run Modify ePub to Remove no dc: metadata from manifest.

Maybe Kiwidude could somehow prioritize the two and ensure if run together that the final result is updated dc: metadata only or add a option to update dc: metadata only.

Edit: Personally I would just like the Update metadata (including cover) option to limit itself to the metadata calibre would insert during a conversion.

Update: When calibre Saves a book to disk it inserts in the ePub all of the same metadata (including the extra custom column junk not included when a book gets converted) that this plugin inserts into book as metadata. Which means, obviously this plugin is using the same code as calibre's Save to disk Feature.

Update 2: When calibre Sends a book to the device it also includes all of the same metadata (including the extra custom column junk not included when a book gets converted) that this plugin inserts into book as metadata. It seems odd to send all of the custom column junk to the device as metadata, but at least now I know how it is currently working and none of it has ever hindered my reading experience in the slightest.

Update 3: Thinking it over the custom column stuff may need to be included for the metadata plugboards. For those folks that just want dc: metadata follow the two steps outlined above and ignore my updates.

I fully agree with you dwanthny. This metadata things has also not hindered my reading experience in the slightest.
I just mentioned it here because it creates sort of an inconsistency between the two functions in Modify ePub that might confuse the users as mentioned by Magnus in post #7.
Maybe the Remove function could be changed to remove "unknown" metadata, i.e. metadata that is not dc conforming and not created by calibre.

There seems to be some confusion from the original poster and some of the subsequent replies about his non dc: metadata issue, so here is the "skinny" from me.

As Dwanthy found, the "Update metadata" option does *exactly* the same as a "Save to disk" does. Which means calibre will insert both dc:xxx elements, but also its own <meta> elements. The latter <meta> elements (along with those created by other ePub editing applications like Sigil) are what are not part of the official ePub specification and hence are not in the dc: namespace.

Do these cause a problem for people? For 99.99% of calibre users, the answer is "not in the slightest". The *only* use case I am aware of that a number of people have asked for is where you are self publishing your own book for uploading via websites. Some of these sites that have rules in place that reject ePubs that have elements in this part of the manifest that are non-compliant with the ePub specification. It's arguably a poor reason to reject ePubs, but nonetheless sometimes there are battles you cannot win.

So using this option in Modify ePub/Quality Check allows that small minority of calibre users to detect and fix such issues prior to publication. For any other user of calibre, you should just ignore the option, it will achieve very little for you.

If you try to tick *both* removing non DC: metadata *and* updating metadata, then you are in some ways shooting yourself in the foot. As I explained above, calibre is one of the "culprits" responsible for inserting non dc elements.

As to why I do not run them in the other order, that is intentional. One of the reasons for using update metadata is to allow people to get their book in the same state as if they did a "Save to disk" without exporting and reimporting it. The only way I can guarantee that this is the case (and that all elements calibre generates for updating metadata are present) is to do this action after any other selection in the Modify ePub dialog. Were I to flip them the other way around, you would be missing for instance the calibre timestamp. Which breaks the "integrity" of "Update metadata". The alternative way around it means it breaks the integrity of "remove all non dc:". Either way something "breaks". As I saw the remove non dc: thing as something few users would bother using, I chose the way I did. If the genuine users of that functionality want it the other way around, then I can look at changing it.

One thing this discussion has highlighted is that the logging could offer a better visual indication as to what it is removing - I will sort that out for the next release.

So - if your intention is to remove all non dc: metadata elements, then don't tick "Update metadata" at the same time - do it in two passes. If you want to remove non dc: elements (such as from other editing applications) except for the calibre generated ones, then you can tick both at the same time.

The problem you are seeing in that output is that you have an old and incompatible plugin called "Goodreads Covers" installed (the predecessor to the "Goodreads" plugin which was a consolidation of two Goodreads metadata plugins that occurred when calibre 0.8 was released).

You need to get rid of that old plugin. Run this from a command line prompt:

Modify ePub can't modify covers that aren't properly defined (which unfortunately is true of many ePubs). What you need for this case is a cover insertion feature, which is on the to-do list for the plugin but probably won't be implemented in the near future.

@Matth79 - this plugin will only replace covers where they are identifiable by calibre (in exactly the same way as using Save to Disk does). If the covers are not getting placed into the ePub correctly, then the problem lies in the ePub. Either use Sigil to mark the appropriate file with the cover semantics, or do an epub->epub conversion using calibre.