Hello

Wondering if anybody else has experienced this problem.

I'm working on a batch of ePub files originally generated from InDesign and then edited in Calibre. I'm now trying to get them into Apple's iBooks using the iTunes Producer app. On doing so, we're told ERROR ITMS-9000, unmanifested file "calibre_bookmarks.txt". I opened up the ePub to delete this unmanifested file (maybe that was a bad idea...) and checked that the file validated, which it did. So in theory, I think, that should be OK for iBooks - but instead I'm now getting "Invalid URI in NCX file".

Any ideas anyone?

Also interested, by the way, in experiences with iTunes Producer. We've tried to upload two titles so far - one is sitting on iTunes connect as "pending" (I wonder for how long?) and the other, though apparently uploaded (and reuploaded) successfully doesn't appear at all. Maybe Apple are having a bit of a backlog?

Thanks
Michael

I'm working on a batch of ePub files originally generated from InDesign and then edited in Calibre. I'm now trying to get them into Apple's iBooks using the iTunes Producer app. On doing so, we're told ERROR ITMS-9000, unmanifested file "calibre_bookmarks.txt". I opened up the ePub to delete this unmanifested file (maybe that was a bad idea...)

That's just a file that calibre's reader adds to provide support for bookmarks without having to maintain them in a separate database. Perfectly safe to delete it.

and checked that the file validated, which it did. So in theory, I think, that should be OK for iBooks - but instead I'm now getting "Invalid URI in NCX file".

Could you post the epub's .ncx file? (It only contains the chapter names, so there shouldn't be a copyright issue.) ePubcheck does basic link-checking, so that shouldn't be an issue, but there might be some odd character in there causing a problem.

Quite a lot of problems people have reported end up boiling down to character-encoding issues, which is why I'd recommend using Sigil to do the editing instead, as it's strict about enforcing UTF-8 in the current version.

i, too, am getting an error at the end of the long itunes producer process. i have now been on the phone with apple for 47 minutes and am getting nowhere. if you have found any help for this, can you post? thanks. gail

I got the same error. I've been working on creating a "pristine" epub for Apple. I'll keep checking bach here and let you know if it works.

Well the original poster never came back, so I assume he fixed his problem. It's impossible to tell what's causing the problem without seeing your .ncx file. But, as before, messed-up characters (improper coding, spaces being turned into %20's, etc) are the most likely cause.

Charleski - I often have code with %20s in place of spaces I've typed. Should I be using an underscore instead? Thx.

Yes, probably safer, though the real problem is whatever software you have that can't deal with spaces in file names.

Well the original poster never came back, so I assume he fixed his problem. It's impossible to tell what's causing the problem without seeing your .ncx file. But, as before, messed-up characters (improper coding, spaces being turned into %20's, etc) are the most likely cause.

Hello again - sorry for going silent, got distracted by something else. Alas I'm still not quite there. I can't post the file as it would identify the book and I'm not sure its owner would want that, but I think you're definitely on the right track – I've had a similar problem on another file which I did eventually manage to get on to iTunes. However I'm not quite sure how I fixed it... Is there a way I can actually see the offending characters easily and change them to what they should be?

The URIs in the ncx file are fairly easy to spot:

...
<navPoint id="navPoint-6" playOrder="6">
<navLabel>
<text>4</text>
</navLabel>
<content src="Text/Section0007.xhtml"/>
</navPoint>
...

You need to check that these filepaths precisely match what's actually in your epub.

I would recommend you run it through epubcheck (http://code.google.com/p/epubcheck/) separately, as that will give the line number on which the error occurred.

The URIs in the ncx file are fairly easy to spot:

...
<navPoint id="navPoint-6" playOrder="6">
<navLabel>
<text>4</text>
</navLabel>
<content src="Text/Section0007.xhtml"/>
</navPoint>
...

You need to check that these filepaths precisely match what's actually in your epub.

Nothe that the paths are relative to where the OPF file is located, thus, if the OPF is "OEBPS/content.opf", the above path would refer to "OEBPS/Text/Section0007.xhtml"

Thanks for that charleski and Jellby.

I've had a close look at the file but I just can't see any link that doesn't match up. In the NCX I have...

<navPoint class="chapter" id="932a1cb0-ec5c-4a75-ac02-9ef00e71d591" playOrder="58">
<navLabel>
<text>Also available</text>
</navLabel>
<content src="OEBPS/split_017.xhtml#also-available"/>
</navPoint>

...and in that file I have a...

<p class="also-available-title" id="also-available">Also available</p>

Don't normally have problems with broken links but I must be missing something obvious here?

Still seems odd that the file validates in epubcheck but is rejected by iTunes Producer.

Best
Michael

Just a thought - have you tried removing the hyphen from the fragment id? Hyphens are legal in fragment ids, but Apple doesn't always follow the standards completely.

Line 105 column 29: unfinished element - i'm getting this error with itunes producer, anyone come across it before? cannot for the life of me figure it out, looked at it so many ways, I'm sure I'm missing something simple. Any help would be great, thanks.

Line 105 column 29: unfinished element - i'm getting this error with itunes producer, anyone come across it before? cannot for the life of me figure it out, looked at it so many ways, I'm sure I'm missing something simple. Any help would be great, thanks.

When I've gotten this via epubcheck, it means I've not specified one or more of:

author
title
publisher

in the metadata. (i.e. within content.opf in the epub archive) I've no clue if this is your problem, just thought I'd post it as it wasn't obvious to me from the error message, just what was lacking.

HTH

Hello all
Just had this from Apple support:

All characters in the URIs must be valid. Non-alphanumeric characters must be properly encoded. For example, a space should be encoded as '%20'. The problem most often surfaces in URIs in the NCX files.

For more information, refer to Metadata, File Formats and Cataloging in the iBookstore FAQS. Thanks!

The ref to the FAQ's is quite handy as well (within iTunes connect) - it seems to have been expanded, last time I looked there were only two questions (both about using iBooks rather than making things for it!)

Will investigate further and post any progress.

@eBookNoir I'm sure you've thought of this, but I think I've had that error with missing out a closing tag in the TOC or in the HTML files. If the latter, you could try validating each file at http://validator.w3.org (or with the developer toolbar in Firefox) to pinpoint the error. Hope that helps...

Michael

Hello all
Just had this from Apple support:

[I]All characters in the URIs must be valid. Non-alphanumeric characters must be properly encoded. For example, a space should be encoded as '%20'. The problem most often surfaces in URIs in the NCX files.
:rofl::rofl::rofl::rofl:
1960 called, they want their teleprinters back.

"id"s in XHTML should not start with a number, that might be an additional problem with the NCX.

"id"s in XHTML should not start with a number, that might be an additional problem with the NCX.

That is most likely the problem. The latest version of epubcheck catches this error in the OPF. I'm guessing MichaelGray is using an older version, or epubcheck doesn't perform the same check for NCX files.

When I've gotten this via epubcheck, it means I've not specified one or more of:

author
title
publisher

in the metadata. (i.e. within content.opf in the epub archive) I've no clue if this is your problem, just thought I'd post it as it wasn't obvious to me from the error message, just what was lacking.

HTH
Actually it passes epub check perfectly, it's when i hit deliver on itunes producer that i get the error, which makes no sense. I have all of those in there from ID and from tweaking the metadata. Thanks for the suggestion though, if anyone else knows why, it'd be great. The one area apple is lacking in is help or service with itunes producer, they need to step it up.

Hello all
Just had this from Apple support:

All characters in the URIs must be valid. Non-alphanumeric characters must be properly encoded. For example, a space should be encoded as '%20'. The problem most often surfaces in URIs in the NCX files.

For more information, refer to Metadata, File Formats and Cataloging in the iBookstore FAQS. Thanks!

The ref to the FAQ's is quite handy as well (within iTunes connect) - it seems to have been expanded, last time I looked there were only two questions (both about using iBooks rather than making things for it!)

Will investigate further and post any progress.

@eBookNoir I'm sure you've thought of this, but I think I've had that error with missing out a closing tag in the TOC or in the HTML files. If the latter, you could try validating each file at http://validator.w3.org (or with the developer toolbar in Firefox) to pinpoint the error. Hope that helps...

Michael
validated the xhtml files - came up with all passing, but the cover one had this error - No Character encoding declared at document level - might be the culprit, now I need to fix and see if that works. that site won't validate toc.ncx files, may have to look at that on its own/. Thanks.

Just to come back on my problem file – problem solved: not the numbers at the beginning of the TOC id's, but the spaces in the paths. It was spaces not in the XHTML file names, but in the name of the folder containing them. Changed those to %20 in the NCX file and it worked. Thanks for your help, everyone - much appreciated.

My client is uploading my epub file to the ibookstore, and has been getting the "ERROR ITMS-9000." I'm cringing as my epub that passed the threepress epub check causes my clients grief.

No luck finding the Metadata, File Formats and Cataloging in the iBookstore FAQs.
I did find an article about which characters are allowed in URIs, including "%encoding"

http://www.rfc-editor.org/rfc/rfc3986.txt. There's an appendix that gives a hierarchy of reserved and unreserved characters.

Susan

I worked on my ePub file in Sigil and now my customer is having trouble uploading it with iTunes Producer. This is the error message that he got:

1 package(s) were not uploaded because they had problems:
/Users/jeffgoforth/Music/iTunes Producer/Playlists/1424316545.itmsp - Error Messages:
Apple's web service operation was not successful
Unable to authenticate the package: 1424316545.itmsp
ERROR ITMS-4000: "Line 88 column 92: bad character content for element at XPath /package/book/assets/asset[1]/data_file/file_name"

This went through the ePub validator with no problems. Any ideas?

Are you uploading a file already seen by iTunes? If so, maybe you should try the unaltered epub file (i.e. before it was assimilated into iTunes).

Gotta say this is among the most unrevealing error messages I have seen in a long time!

What is the first asset listed on the asset tab of iTunes Producer? Info from the other thread on Apple's crappy validation system suggests there'll be something in that file that doesn't match their requirements (probably completely unrelated to the file name).

I think I figured my problem out. I had multiple image files in the ePub package that had spaces in their names. Sigil understood this in the HTML coding by adding %20 but the file names still had spaces in the images folder. When I renamed them without spaces: like title_page.jpg the file uploaded successfully. Sigil was even smart enough to know to change the image name in the HTML for me so I didn't have to change them myself. Such a simple solution, really, but absolutely NO indication in the error messages that that was the problem. What a relief!

I think I figured my problem out. I had multiple image files in the ePub package that had spaces in their names. Sigil understood this in the HTML coding by adding %20 but the file names still had spaces in the images folder. When I renamed them without spaces: like title_page.jpg the file uploaded successfully. Sigil was even smart enough to know to change the image name in the HTML for me so I didn't have to change them myself. Such a simple solution, really, but absolutely NO indication in the error messages that that was the problem. What a relief!

Apple is really being silly here. As long as a space is percent-encoded in the URI's, an RS should be able to handle it just fine. That's why we have percent-encoding. Not to mention that this is exactly what the spec says should be done in these instances, since spaces in filenames are allowed.

Michael,
I've checked the characters in my URIs, even files without any spaces or non-alphanumeric characters are "unmanifested" even though they are listed in my content.opf file between <manifest></manifest>tags.

Here's the error message:
ERROR ITMS-9000: "Unmanifested file found : tofu_quilt.epub:/__MACOSX/OEBPS/._Acknowledgements.xhtml" at Book (MZItmspBookPackage)
ERROR ITMS-9000: "Wrong namespace in tofu_quilt.epub:/__MACOSX/OEBPS/._Acknowledgements.xhtml : null - expecting http://www.w3.org/1999/xhtml" at Book (MZItmspBookPackage)

I double-checked, the namespace is at the top of the xhtml file.

I can't figure out why iTunes Producer is finding a "__MACOSX/" "._ " before all the filenames.

Any ideas?

Thanks! Susan

Whatever tool you're using to produce your epub is zipping up the resource forks as well.

charleski,
Thanks! Now I understand the strange filepaths.
I switched to Sigil, and the file uploaded just fine. Many thanks to Valloric.
Susan

This really does concern me. So even if our files come back validated, Apple still may find errors?

I think I figured my problem out. I had multiple image files in the ePub package that had spaces in their names. Sigil understood this in the HTML coding by adding %20 but the file names still had spaces in the images folder. When I renamed them without spaces: like title_page.jpg the file uploaded successfully. Sigil was even smart enough to know to change the image name in the HTML for me so I didn't have to change them myself. Such a simple solution, really, but absolutely NO indication in the error messages that that was the problem. What a relief!

I am getting this exact same error. I have looked very carefully through the assets in my EPUB and there are no spaces in any of the filenames.

My file passes epubcheck, and I am using zip on the command line in OS X to make sure that no extraneous Mac OS files get zipped.

Any more ideas from anyone?

I worked on my ePub file in Sigil and now my customer is having trouble uploading it with iTunes Producer. This is the error message that he got:

1 package(s) were not uploaded because they had problems:
/Users/jeffgoforth/Music/iTunes Producer/Playlists/1424316545.itmsp - Error Messages:
Apple's web service operation was not successful
Unable to authenticate the package: 1424316545.itmsp
ERROR ITMS-4000: "Line 88 column 92: bad character content for element at XPath /package/book/assets/asset[1]/data_file/file_name"

This went through the ePub validator with no problems. Any ideas?
In your case, did "asset[1]" actually correspond to a specific file in your EPUB? I have the same error with "asset[2]" and I'm trying to figure out exactly what file inside the EPUB it is referring to.

In your case, did "asset[1]" actually correspond to a specific file in your EPUB? I have the same error with "asset[2]" and I'm trying to figure out exactly what file inside the EPUB it is referring to.

Possibly your image file. Since they ask for 600 px high, maybe the image file is a little too small? Someone else had mentioned that. And then it also should be named ISBN13.jpg.

Another thing could be the metadata you're entering in the form. Some of the fields are required. Page count, book description, etc. Just get as much info in there as you can.

I finally got my file to pass all the validation but then get this: since I had uploaded it on my Apple ID, I am now not able to load it on my client's ID. Since the ISBN13 is the key field, they won't allow duplicates. C'mon!! The saga continues...

Idespain, it actually turned out to be a copyright symbol: ©
I had one in my content.opf file in the rights metadata and one in the copyright page XHTML file of my EPUB. I don't know which caused the problem. Perhaps if I had only removed one, the other would have tripped the same alarm. I changed them both to "(c)" and everything was fine.

I'm not surprised, to be honest, that Apple has more stringent requirements than epubcheck, but they should tell us exactly what they are, and their error codes should be more precise, or at least quote the part of the file that is problematic. A copyright symbol should be allowed. It is within the UTF-8 character set that EPUB requires!

Idespain, it actually turned out to be a copyright symbol: ©
I find this really amusing :D

Idespain, it actually turned out to be a copyright symbol: ©
I had one in my content.opf file in the rights metadata and one in the copyright page XHTML file of my EPUB. I don't know which caused the problem. Perhaps if I had only removed one, the other would have tripped the same alarm. I changed them both to "(c)" and everything was fine.

I'm not surprised, to be honest, that Apple has more stringent requirements than epubcheck, but they should tell us exactly what they are, and their error codes should be more precise, or at least quote the part of the file that is problematic. A copyright symbol should be allowed. It is within the UTF-8 character set that EPUB requires!

Get outta town! That is the silliest thing I've heard lately. Good to know though - thanks for posting!

Get outta town! That is the silliest thing I've heard lately. Good to know though - thanks for posting!

Agreed: silly. And it says nothing of this or any other type of UTF-8 disallowed characters in the iBookstore Publisher User Guide 1.3.

Try & #169; or &copy; instead of (c). That is the html code for © and should work. Even for Apple....

Remove the space between the & and #. The forum immediately translates it otherwise.

I always tend to use html code for symbols and accented letters.

Apple's web service operation was not successful
Unable to authenticate the package: 1424316545.itmsp
ERROR ITMS-4000: "Line 88 column 92: bad character content for element at XPath /package/book/assets/asset[1]/data_file/file_name"

This went through the ePub validator with no problems. Any ideas?[/QUOTE]


I had the same problem uploading my epub to Apple. It was fixed by removing the ellipsis that was somehow inserted at the end of the file name for the epub. Don't know how it got there but the ellipsis was causing Apple to reject the entire file.

Idespain, it actually turned out to be a copyright symbol: ©

A "©" is okay in the body of a document. Where the glitch comes in is adding it inside metadata. That's my experience. - Fabe

Possibly your image file. Since they ask for 600 px high, maybe the image file is a little too small? Someone else had mentioned that. And then it also should be named ISBN13.jpg.

Apple's requirement is that Covers be at least 600 px on the shortest side. They do not need to be ISBN-13 named. Non-cover graphics can be any size. - Fabe

Where are you guys getting these Apple error messages? Are you uploading from your Mac computers directly to the iBookstore?

Not being Mac enabled, I am using Lulu as an aggregator.

Where are you guys getting these Apple error messages? Are you uploading from your Mac computers directly to the iBookstore? Not being Mac enabled, I am using Lulu as an aggregator.

Oldpilot, Yes, I use a Mac and yes, I do my own uploading as an Apple Publisher. My errors not only come from Apple, but also from epub validation. -Fabe

Further information for others...

I came across a similar error, but the line was "....suggested_retail_price".
This was a problem in the .itmsp, not the .epub.

Turns out that if you use a tab delimited file to generate your metadata (as you would for multiple titles), you should use a "." in any Euro Physical List Price, rather than the more correct ",".

iTunes Producer (2.2.1) will still display it as "," but if it is "," in the .itmsp it throws an error.

I ended up fixing this by hand by editing each .itmsp file in Text Wrangler. Trying to correct it directly in iTP didn't work.

d.

Hello everyone,

Although I have successfully uploaded three titles to the iBookstore, I get an error on 2 out of 3 books I try to upload.

All EPUBS validate with Epubcheck and Flightcrew and adhere to all Apple standards. When I use iTunes Producer, the file is validated and delivered. After it doesn't show up on my iTunes Connect account, I check the Package History window in iTP and see that under "state" I get "Import Error", instead of "Imported".

There is no further explanation on the error, and Apple support will not reply to any of my emails (although they have acknowledged receipt)

Any tips ?
Thanks
Nick

nargyris,
Could there be a problem with the information in the iTunes Producer information? Perhaps you could find a difference between the successful and unsuccessful files in the book information fields.
Also, are the cover files the right size and file format?
Good luck!