Umm, all the plugin does is invoke kindlegen.

kindlegen is responsible for creating output that is sane according to Amazon's standards.

I am not sure that is the problem, as the .mobi file works properly. It is only the .azw3 being split out by the plugin that has the problem. Is it possble that something is being missed in the split process?

Dave

As NiLuJe said, the fault lies further on, with KindleUnpack.

Which is also something that the plugin is not responsible for -- go ask the KindleUnpack folks: https://www.mobileread.com/forums/showthread.php?t=61986

Unless I am missing something, the problem is the lack of an ASIN in the .azw3(KF8) file. These books do have an ASIN, but I guess it gets lost somewhere in the KindleImport/edit/Kindlegen process. How do I add the ASIN back in after the work is done? Did I miss a setting?

Dave

PS: looks like I did, I just set add_asin = True

This plugin is not designed to be used with ePubs generated by KindleImport.

However, you can have it automatically add an ASIN, by changing the following kindlegen.ini setting:

The plugin will then look for a metadata entry with the following format in the metadata section of the .opf file:

or

If it doesn't find one of these entries it'll generate a fake ASIN.

BTW, KindleUnpack will write the original ASIN as a comment to the re-generated .ePub. This commented-out ASIN will NOT be found by the plugin. You'll need to manually add it to the metadata section.

If this setting is enabled, it'll also generate a cover thumbnail for the .azw3 book that you'll need to copy to the /system/thumbnails/ folder.

BTW, if you just want to touch up some Kindle books, Calibre Editor is much better suited for this task, because it'll automatically unpack and reassemble AZW3 books.

Of course the ASIN gets lost in that process. Think about it:
KindleImport makes an azw3 an epub. Epubs don't have ASINs. Then you run that ASIN-less EPUB through Kindlegen (via the kindlegen plugin) to make it a dual format mobi. There's still no ASIN because kindlegen doesn't give its output ASINs. That happens later in the KDP process of making your book available for purchase on Amazon (or by using the fake/existing asin generation method Doitsu mentioned above).

There is no ASIN in the KF8/azw3 after splitting with KindleUnpack because the Kindlegen output didn't have an ASIN. It couldn't (again: unless you use Doitsu's method). The KindleUnpack split feature could make something up for an ASIN, but quite frankly, KU isn't in the business of manufacturing data that's not present.

Has anyone checked to see if KindleUnpack's split feature will honor the supplied (or faked) ASIN that kindlegen can be coerced into adding? If it doesn't, that would be the only way I could see that KU was doing anything "wrong." Otherwise it's a case of KU's splitter choosing to not make-up data that doesn't exist in the kindlegen output in the first place.

DiapDealer, the problem is that kindlegen generates dual-MOBIs which on the Kindle get an old-style hash for the cdeKey, and then KindleUnpack gives that a null value.

As far as the Kindle is concerned, a MOBI/AZW3 should either have an ASIN (calibre can create this, as can KevinH's dualmetafix) OR it should be a PDOC with a hash, but the KindleUnpack-split book is somehow breaking PDOCs, because they have neither.
Or:
It definitely appears to be a problem ;) but it also has nothing to do with either this plugin or ASINs. :shrug:



And now, I really think this discussion should move on over to the KindleUnpack thread, if anyone wants to continue discussing it.

Late to the party (well, over here anyway ^^), but I definitely agree with @DiapDealer that KU should absolutely not add stuff that wasn't there in the first place.

The fact that the Kindle framework can't deal with an ASIN-less KF8 properly is a bummer, but, well, out of KU's scope, I think? (KU is just doing its job, if there's an ASIN in the source file, there'll be one in the output ones).

Because after all, why the framework just craps out in fun and interesting ways with ASIN-less KF8 files instead of choosing to generate a md5 hash like it does for ASIN-less M7 or dual files is kind of a mystery...

It's just one of those quirks that one should be aware of when dealing with that kind of stuff. Which is why I'm happy to see that this plugin *does* have a way to handle it seamlessly ;).

So, yeah, maybe add a spiel to the relevant setting somewhere about how brokenly the Kindle (well, FW 5.x at least) handles KF8 files if there's no ASIN set, but that's about it. Can't make too many assumptions about what people will do with these files, after all ;).

Be that as it may; I was primarily addressing dhdurgee's statement concerning ASINs getting "lost" in his process involving this plugin. Which they most certainly are.

And if Kindlegen can be coerced into providing real (or fake) ASINs (and if KU's splitter keeps them), then I would say that ASINs are extremely relevant to the discussion. I mean, there must be a reason calibre is creating fake ASINs for its stand-alone KF8s, no? If it didn't, wouldn't those .azw3s suffer from the same problem (under NiLuJe's scenario)?

Hey NiLuJe. Nice to see you. :)

@DiapDealer: From a (very) quick glance at the plugin code, KindleGen doesn't really enter the equation, the plugin's using the dualmetafix python script to add a 12 character one from a cropped random uuid (I'm guessing to more closely match the length of a real ASIN) to the metadata of the KG output.

Since it's mobi header metadata, KU properly preserves that when splitting. So, all's well ;).

It's just that the option is disabled by default, and one may not be aware that trying to use such KF8 files directly will risk upsetting the Kindle's framework ;).

And while doing it by default makes sense for Calibre, I'd argue that @Doitsu's choice was the right one here? He documented most of the underlying issues fairly well, and even I had forgotten how deeply messy it could be, so ;p. (That, or it got 'worse' since FW 5.5.x. But I'm way too lazy to check on an older device ^^).

@NiluJe: oh ... my bad. I assumed Doitsu's ini setting influenced kindlegen's behavior. I didn't realize dualmetafix was part of the plugin.

@Doitsu: any interest in having your plugin grab the asin from the comment in KU's output? Or if it would make things easier for everyone, I wouldn't mind modifying my KindleImport plugin to create the ASIN dc metadata entry that your plugin looks for. It'd be a pretty-quick opf diddle on my end. ;)

Can I enter the above identifier entry via the Sigil Metadata editor? How would I need to do so?

Dave

I'd really appreciate it, if you did that, because the KindleGen plugin has become so unwieldy that I'm a bit reluctant to introduce further changes.

1. Press F8, click Add Basic, select Identifier (Custom) and click OK.
2. Double-click customidentifer and change it to AMAZON or MOBI-ASIN.
3. Double-click the empty Value field and enter the ASIN number.

However, it'd much easier to simply copy

to the metadata section of the .opf file and to manually edit the ASIN number.

Thank you for your guidance in this area. Per your suggestion I have installed Calibre on my system and will use it to tweak the .azw3 books as opposed to using KindleImport and KindleGen with Sigil. I will continue to use Sigil in other cases, such as creating books from internet content. In that case I might be using KindleGen, but I am going to see how Calibre works with them as well.

Dave

How does the kindlegen plug-in add the ASIN when the option is selected? Is there an undocumented kindlegen option to this effect, or is it post-processing the generated file?