An kepub which does not want to import into my kobo clara hd

[Planetibo]

Good morning!
Thank you very much for the development of kepubify, I use it regularly to read epubs of books that I have in paper version.
It sometimes happens to me that certain kepubs are not detected by the kobo clara hd even though the epub file is detected.
When I unplug the kobo I see the import progress bar and it disappears and the kepub book is not present.
I don't know why, does the kobo generate a log file to undertand what appends during the importation?
I can send you an epub for the example.

[pgaskin]

You can check the syslog by running logread with NickelMenu or telnet. That may have some information. I also recommend validating the EPUB file; if you give kepubify garbage, it will result in garbage. If you send me the EPUB, I can see if there's anything obviously wrong with it, but I don't currently have time to look at it in depth.

[paul-2021]

I am getting something similar with some (but not all) converted files. Some converted files do not appear when sideloaded, but the originals work fine. The input is valid and passes epubcheck. The converted version fails.

My Kobo Clara BW reports a nice vague "This epub file is bad!" error when importing. kepubify is sometimes creating epub files with a bad zip header. 7Zip vaguely complains that the header is invalid when testing. epubcheck gives a more useful error:

"zipfile.BadZipFile: Corrupt extra field 5500 (size=1364)
Error: Corrupt extra field 5500 (size=1364)"

The conversion was run on a Raspberry PI.

Note that some utilities will silently ignore the error. Kobo and epubcheck refuse to open it.

[paul-2021]

In one file, there are some correct entries and some that have a broken Extended Field extra data block.

Using zipinfo -v

`Central directory entry #21:
---------------------------

  There are an extra 16 bytes preceding this file.

  OPS/005-Dedication.xhtml

  offset of local header from start of archive:   2869925
                                                  (00000000002BCAA5h) bytes
  file system or operating system of origin:      MS-DOS, OS/2 or NT FAT
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          yes
  file last modified on (DOS date/time):          2025 Jan 14 09:33:00
  32-bit CRC value (hex):                         5e1074a6
  compressed size:                                343 bytes
  uncompressed size:                              569 bytes
  length of filename:                             24 characters
  length of extra field:                          46 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  non-MSDOS external file attributes:             810000 hex
  MS-DOS file attributes (00 hex):                none

  The central-directory extra field contains:
  - A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes.  The first
    20 are:   00 00 00 00 01 00 18 00 00 ae 2c 4d 67 66 db 01 00 ae 2c 4d.

  error: EF data block (type 0x5500) size 1364 exceeds remaining extra field
         space 6; block length has been truncated.**

  - A subfield with ID 0x5500 (unknown) and 6 data bytes:
    00 01 4c 2f 86 67.

  There is no file comment.`

[paul-2021]

The same file in the original epub is:

Central directory entry #8:
---------------------------

  OPS/005-Dedication.xhtml

  offset of local header from start of archive:   3144
                                                  (0000000000000C48h) bytes
  file system or operating system of origin:      NTFS
  version of encoding software:                   2.3
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          no
  file last modified on (DOS date/time):          2025 Jan 14 09:33:00
  32-bit CRC value (hex):                         187533fa
  compressed size:                                305 bytes
  uncompressed size:                              457 bytes
  length of filename:                             24 characters
  length of extra field:                          37 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  non-MSDOS external file attributes:             810000 hex
  MS-DOS file attributes (00 hex):                none

  The central-directory extra field contains:
  - A subfield with ID 0x000a (PKWARE Win32) and 32 data bytes.  The first
    20 are:   00 00 00 00 01 00 18 00 00 ae 2c 4d 67 66 db 01 00 ae 2c 4d.

  There is no file comment.

It only seems to affect the files that are transformed (*.xhtml, *.opf). It appears that modifying the file and preserving the old binary extra data is somehow corrupting the writing of headers. The reported length of the extra field is different.

In this case, the file system has changed and presumably the library is attempting to write a block for FAT32 (which is wrong anyway because it was EXT3) and using the old NTFS extra data. Preserving the file system properties may also preserve the extra info. However, if the compression method changes I have no idea if different schemes put anything in there.

[paul-2021]

I thought I would have a go at changing it locally. Setting:

                CreatorVersion: f.CreatorVersion,
		ReaderVersion: f.ReaderVersion,
		Flags:         f.Flags,

Didn't make a difference, but it does preserve some of the original properties of the file. CreatorVersion just gets overwritten anyway and ReaderVersion is probably also overwritten.

The only thing that fixed it was to omit the copying of the extra data and let the library generate it's own. This now works and imports into the Kobo. The corrected information (with copying of Flags) is:

Central directory entry #29:
---------------------------

  There are an extra 16 bytes preceding this file.

  OPS/005-Dedication.xhtml

  offset of local header from start of archive:   2901524
                                                  (00000000002C4614h) bytes
  file system or operating system of origin:      NTFS
  version of encoding software:                   2.0
  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
  minimum software version required to extract:   2.0
  compression method:                             deflated
  compression sub-type (deflation):               normal
  file security status:                           not encrypted
  extended local header:                          yes
  file last modified on (DOS date/time):          2025 Jan 14 09:33:00
  file last modified on (UT extra field modtime): 2025 Jan 14 09:33:00 local
  file last modified on (UT extra field modtime): 2025 Jan 14 09:33:00 UTC
  32-bit CRC value (hex):                         5e1074a6
  compressed size:                                343 bytes
  uncompressed size:                              569 bytes
  length of filename:                             24 characters
  length of extra field:                          9 bytes
  length of file comment:                         0 characters
  disk number on which file begins:               disk 1
  apparent file type:                             binary
  non-MSDOS external file attributes:             000000 hex
  MS-DOS file attributes (00 hex):                none

  The central-directory extra field contains:
  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
    The local extra field has UTC/GMT modification time.

  There is no file comment.
`

Note the different extra field data.

[paul-2021]

@pgaskin I don't know whether you have noticed, but in the comment above there's a fix for kepubify sometimes creating corrupt zip files that fail to import on the Kobo. Thanks for the work you are doing. It all goes a long way to making my Kobo usable in sideload mode.

[pgaskin]

Yep, I'll integrate this fix in the next release.

[paul-2021]

Great. Note that I applied this for both modified files and those that are copied just to be sure that there isn't some situation where the library changes the extra data. I haven't tested just changing it for modified files only.