View Single Post
Old 11-11-2013, 02:35 PM   #88
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 7,644
Karma: 5433388
Join Date: Nov 2009
Device: many
can verify problem

Hi Paul,

Please try the attached DumpMobiHeader_v014.py on a Kindlegen 2.9 generated mobi. You will see that there is now an extra BOUNDARY followed by a CONT section (container) that has its own exth and which has following sections where they are keeping high definition format copies of specific images.

I have modified DumpMobiHeader_v014 to at least show those new sections and dump the exth values in the new CONT header. There are other values in the CONT header as well but I am not sure what any of them are yet.

My guess is that the Kindle Fire and HD use these high resolution images stored outside the mobi 6 part and that somehow when kindlestrip removes the SRCS sections it is throwing off the code that accesses these now shifted high definition images.

My rec would be to go back to nulling out the SRCS sections so that we don't upset any offsets to images we do not understand yet.

I have attached the latest DumpMobiHeader_v014.zip here so please look at the original mobi using it and see if that makes any sense to you.

Take care,

KevinH
Attached Files
File Type: zip DumpMobiHeader_v014.zip (5.7 KB, 413 views)
KevinH is offline   Reply With Quote