Hi DiapDealer,
It seems the exth_flags value found in the mobi header at bytes 0x80 - 0x83 is the culprit. They seem to have expanded this to have new flags.
In all regular old mobi ebooks with an exth this value is 0x0050 (0x0040 is the bit that indicates there is an exth section).
All of the split mobi7 files have the value 0x1850 here so it appears the first two bytes of this flag field are being used for something.
If I do the following in the right place in mobi_split.py
flgval, = struct.unpack_from('>L', datain_rec0, 0x80)
flgval = flgval & 0x0050
datain_rec0 = datain_rec0[:0x80] + struct.pack('L',flgval) + datain_rec0[0x84:]
just before datain_rec0 is written back near the end of the mobi7 stage.
Then when I fire it up in Kindle Preview set for Fire it shows up with no errors.
So we will probably have to figure out what those extra bits mean in that extended field in order to figure out how to deal with them properly. Something in there is convincing the Kindle Previewer that this is a dual mobi kf8 ebook.
Kevin
Quote:
Originally Posted by KevinH
Hi,
I tried removing all metadata that was K8 specific. I tried removing all metadata that talked about creator software versions. I noticed that the FCIS sections where different between old mobis that Kindle Previewer in Fire mode showed well and these split versions and modified the software to create the old style FCIS (FLIS) was the same. I even put back the font and resc files instead of zeroing them out, and still no luck!
Somehow somewhere there must be something in the mobi7 split file that confuses the Kindle Previewer when in Fire mode but I really can not see it.
I dumped the mobi7 header.dat and the header.dat form one version create with a mobi to mobi conversion in calibre and compared them. I simply can not find much different that might matter in any way.
|