Broken EPUB (missing files): JPEG Image not listed in manifest

[JGrubb]

General Problem
I keep getting an error message when I try to upload my EPUB file on Smashwords:

"File 'Illirium_Map_There_was_Music.jpg' in EPUB not listed in manifest! Your .epub file is missing one or more elements in its manifest. . . ."

After extensive review, and scouring the internet for troubleshooting solutions, I cannot figure out how to resolve this. I have run the EPUB through another EPUB Validator, which finds no errors (see attached screenshot), and reviewed the manifest manually using Calibre (via the content.opf listing - see attached screenshot), which shows the image in question as part of the manifest - with consistent naming. Moreover, the files are clearly listed in the directory, and no other aggregator site has raised this problem with the exact same EPUB file.

Smashword Response, Part 1
I contacted the Smashword Service Team, and using my actual EPUB file, a member reviewed it with their tech team. He responded:

"I had our techies take a look at the EPUB and they suspect it's due to the formatting of the underlying HTML for that particular file in your EPUB manifest. Specifically, they suspect it's due to the "../" in the HTML for the file in question:

<item id="id1" href="../Illirium_Map_There_was_Music.jpg" media-type="image/jpeg"/>

By contrast, your other elements include the exact directories, e.g.:

<item id="image_cover" href="Images/d84614660b3bc605c904b4cb49ac72bc55c6934e_smallRaw. jpg" media-type="image/jpeg"/>

<item id="content_8_part-2-wilderness" href="Text/8_part-2-wilderness.xhtml" media-type="application/xhtml+xml"/>

Updating the href attribute to explicitly include the entire directory will likely fix the issue.

Question about Calibre
I originally entered that image using Calibre, while the rest of the EPUB was generated by Reedsy, the former took the complete file name "Illirium_Map_There_was_Music" and added the ".../" preceding it for some reason. I've tried removing and re-adding the image file a couple times, but the same result occurs.

Trying to edit the ePUB manually, I do not appear to be able to change the registry listing (i.e. removing the ".../") without creating a link error within the EPUB, which removes the image.

Smashword Response, Part 2
Inquiring further about this, the representative responded:

You'll need to move the image out of the root directory into the oebps directory, and update the link to the image everywhere it's used through out the book as well as the manifest.

Lingering Question
Does anyone know how to do this, if that is indeed the problem? Or is there something else I am missing? Again, this error has not come up with any other eBook aggregator.

Thank you very much for your time and help.

[theducks]

look at the OPF entry for that file.
now look at the other images entries
it is missing images/<filename>

[JGrubb]

Thanks for providing feedback. I had tried that, and tried it again; but writing in "images/" ahead of the file name (in place of "../") and the file placement location and/or the OPF appears to break the link, removing the image from view.

[Techbar]

Originally Posted by JGrubb

Thanks for providing feedback. I had tried that, and tried it again; but writing in "images/" ahead of the file name (in place of "../") and the file placement location and/or the OPF appears to break the link, removing the image from view.

Did you try 'images' with a capital 'I' ? I think it is case sensitive.

[JGrubb]

Thank you for the additional thoughts. I tried that, both ways ("Images/" or "images/") not yielding productive results.

I even tried shortening the file name, wondering if the "../" was due to a longer name, but that didn't make a difference.

Moreover, I experimented by adding a new random file from my computer, which was also given a "../" before the file name, so that suggests a Calibre default.

As the EPUB has not been flagged by any other aggregator, and the file naming is consistent within the EPUB (as visible using Calibre), I wonder if the Smashwords quality check (presumably AI-based) just doesn't know what to do with the "../". Judging by their website interface for authors, perhaps they are using an older framework for checking EPUB files. Unless I am missing something.

[Quoth]

Export from Calibre as an RTF if you don't have Wordprocessor source.
Make sure everything such as headings, styles and images are OK in the Wordproccessor (Word or LO Writer). Save in native format for later edits. Save AS in docx.
Import Docx to Calibre.
Make sure page format settings is Tablet.
Make an epub2.
Upload that to Smashwords, Google, Amazon KDP etc as desired.
I've had 100% success with that and no issues with TOC or images for years.
Though all our source texts are either our own LO Writer documents or Public Domain Mobi files (We don't upload those anywhere and usually convert direct to epub to read on a Kobo. Sometimes we export PD or Amazon mobi or AZW as RTF and edit to fix severe formatting issues for our own reading.

Only items to be in the System TOC should have a heading level.

[JSWolf]

Originally Posted by Quoth

Export from Calibre as an RTF if you don't have Wordprocessor source.
Make sure everything such as headings, styles and images are OK in the Wordproccessor (Word or LO Writer). Save in native format for later edits. Save AS in docx.
Import Docx to Calibre.
Make sure page format settings is Tablet.
Make an epub2.
Upload that to Smashwords, Google, Amazon KDP etc as desired.
I've had 100% success with that and no issues with TOC or images for years.
Though all our source texts are either our own LO Writer documents or Public Domain Mobi files (We don't upload those anywhere and usually convert direct to epub to read on a Kobo. Sometimes we export PD or Amazon mobi or AZW as RTF and edit to fix severe formatting issues for our own reading.

Only items to be in the System TOC should have a heading level.

Why go through all that nonsense of converting and then converting again. This can only lead to a mess being made of the code. Don't do it.

[JSWolf]

Originally Posted by JGrubb

Thank you for the additional thoughts. I tried that, both ways ("Images/" or "images/") not yielding productive results.

I even tried shortening the file name, wondering if the "../" was due to a longer name, but that didn't make a difference.

Moreover, I experimented by adding a new random file from my computer, which was also given a "../" before the file name, so that suggests a Calibre default.

As the EPUB has not been flagged by any other aggregator, and the file naming is consistent within the EPUB (as visible using Calibre), I wonder if the Smashwords quality check (presumably AI-based) just doesn't know what to do with the "../". Judging by their website interface for authors, perhaps they are using an older framework for checking EPUB files. Unless I am missing something.

Here's what you can do to find out just where in the ePub your images are. Add .zip to the end of the ePub's filename. Then open it with whatever you use to handle ZIP files. Have a look and see where the images are in relation to the HTML and once you've figured this out, rename the ePub again removing the .zip. Then you can edit it and fix the image links.

[Doitsu]

Originally Posted by JGrubb

Does anyone know how to do this, if that is indeed the problem?

If EPUBCheck didn't report any problems, it's definitely a SmashWords problem.

The following might work for you:

1. Open the book with Sigil.
2. Select Restructure Epub to Sigil Norm.
3. Save the epub under a different name.
4. Check the new epub with EPUBCheck.
5. If EPUBCheck doesn't report any errors, upload the new epub to SmashWords.

[Quoth]

Originally Posted by JSWolf

Why go through all that nonsense of converting and then converting again. This can only lead to a mess being made of the code. Don't do it.

Because in YEARS of uploading epubs to Smashwords AND KDP that were imported as docx to Calibre and converted I've not had a problem with images or TOC. Without having to edit the ebook epub/HTML/CSS ever. Proper use of styles, headings, links and images in the source document.

The files are actually created and edited in LO Writer odt native format and an EXTRA save as docx done. Abandoned MS Word in 2016 and Windows in 2017, though I do have Word 2003 on WINE for checking, if I needed it, and Word 2007 in a Windows VM also for checking.
I've not needed either.

Loads of people would be seeing this if it was a Smashwords problem.

[Hitch]

Originally Posted by JGrubb

Thank you for the additional thoughts. I tried that, both ways ("Images/" or "images/") not yielding productive results.

I even tried shortening the file name, wondering if the "../" was due to a longer name, but that didn't make a difference.

Moreover, I experimented by adding a new random file from my computer, which was also given a "../" before the file name, so that suggests a Calibre default.

As the EPUB has not been flagged by any other aggregator, and the file naming is consistent within the EPUB (as visible using Calibre), I wonder if the Smashwords quality check (presumably AI-based) just doesn't know what to do with the "../". Judging by their website interface for authors, perhaps they are using an older framework for checking EPUB files. Unless I am missing something.

Have you disassembled and reassembled it?

This is really a very interesting problem!

Hitch

[JGrubb]

Originally Posted by Doitsu

If EPUBCheck didn't report any problems, it's definitely a SmashWords problem.

The following might work for you:

1. Open the book with Sigil.
2. Select Restructure Epub to Sigil Norm.
3. Save the epub under a different name.
4. Check the new epub with EPUBCheck.
5. If EPUBCheck doesn't report any errors, upload the new epub to SmashWords.

Thank you for your feedback. This was definitely the simplest approach (and worked). I suppose this suggests some quirk with Calibre; though, again, I had no problems with all the other aggregators (Amazon KDP, B&N, Kobo, etc.) using the ePUB file mildly edited using Calbre that had been flagged by Smashwords. Anyway, point to Sigil for helping this problem.