Quote:
Originally Posted by kiwidude
Thx Wallcraft. Sounds like I should include them in the "missing" results then, which they are not currently.
Which brings me onto some more questions: - Is there a need for separate ASIN and EBOK checks? What would people prefer - as it is now or a single check which had the details of what was missing in the log? I don't know what I would call a single check though. If I called it something device specific like "Check invalid for Kindle Fire" then it causes a headache when Amazon releases its next generation of devices...
- ElizabethN found an interesting case - catalogs generated by calibre. If you generate in MOBI, it sets the cdetag to be NWPR. What happens to these on a Kindle Fire? Is that desirable? Should I exclude books in your library with the "Catalogue" tag so they don't end up in the results, or should they be included?
- How are users going to "remedy" mobi files that need changing? Obviously a MOBI->MOBI conversion is one way, though potentially extreme. I see ElizabethN is mentioning a manual process of a third party tool. It seems to me that perhaps there could either be an addition to the "Fix" menu, or maybe even a "Modify MOBI" plugin. I am hesitant to suggest the latter because it opens up all sorts of cans of worms for the future (like people wanting to then be able to do similar things they can do with Modify ePub such as updating metadata, covers, smarten punctuation etc). That is way more than I want to think about (and since I always keep ePub and my MOBI files are converted from that master ePub I personally would never use it which makes me even less enthusiastic about the time spent on it). So "maybe" an entry on the Fix menu of this plugin is something I would consider... maybe...
- If automating such a "fix", replacing the cdetag with EBOK should be straightforward. But what about a missing asin? Where does that come from? Does the value matter?
|
(1)I would prefer keeping the 2 checks separate - cdetype and asin. The info that I get from each I can use in different ways when updating files for the fire or for the keyboard.
(2)"catalogue" tags could flag in the "not ebok" tag result, looking over the log gives more specific results like the NWPR tag. Surprisingly I didn't have flags in the report as PDOC or EBSP (sample) and I thought that I had a few of each in my library. So I probably wouldn't want non-ebok tags excluded in the results as long as I can review the log. Can the log list results in groups of cedtype - none, pdoc, nwpr - or does it do that already?
(3)fixing the problems - if I have my epub and/or mobi master file, I'd just do an AZW3 conversion as that has resulted in fire "book" files each time (so far). for the few books that can't be converted yet to AZW3 (at least one error in the original that crashes the conversion per calibre), either a mobi-mobi conversion or manual update is usually sufficient.
If there was an easy (for you) addition to the results that would enable the file(s) to be fixed, that would be great. Otherwise, I have no need to modify most mobi files other than the EXTH header, annoyances within documents I usually fix in an epub file then convert. 1 vote for NO modify mobi plugin.
(4)cdetype could be a simple change to EBOK (or PDOC depending on need).
ASIN is not as simple a fix depending upon your desired result. If you just want something in field 113 so that you can send the file to books on the fire or sync on the keyboard, "any" value seems to work. I think calibre conversions result in some type of uuid (??) in field 113.
If you want to "share" on facebook or twitter at the end of the book using the keyboard, then field 113 has to be the ASIN specific for the kindle store ebook, plus the same ASIN has to be in field 504 also.
Bottom-line, I'm happy to go with the decisions of the plugin creator. The current additions have been very helpful.
My very long-winded thoughts, now off to work.