Baffled by 'table of contents' behaviour

I’m having a day of hell and hope someone can help. It all revolves around table of contents for .mobi (Kindle) format. I’ve produced several books recently and got them working just how I wanted them. They are novels in parts - and in the contents (both at the side of the Kindle window, and the actual contents page) they came out with Part 1 - name; then chapter one - name etc. All very logical and hierarchical.
Now, with my latest book, I cannot get it to work right. I’ve done everything. I’ve tweaked every conceivable option in the compile setting. I’ve recreated the book any number of times - creating it again from scratch using the novel in parts template; using my previous books as templates and importing the text across. No matter what I do - and this has consumer hours and hours - I can never get the ‘parts’ folders to be included in the table of contents. The chapter numbers are also not appearing in the TOC - even though they are being inserted in the actual text of the book.

Okay - so my main question: there’s been a recent update. Could this have changed anything with how the TOC is generated?

And a secondary question: Is there a way to control how the TOC is created? I can’t find anything in the manual on this.

Has anyone else experienced anything similar?


To your first question, no, nothing has changed in this regard.

To your second question, the table of contents is based off of the contents of the binder and how things are separated. Documents are divided by section breaks (or page breaks - they are the same thing). When Scrivener encounters a page or section break (as defined in “Separators” or via “Page break before”) it will know that’s the end of the section and will include the title of the next section in the table of contents. The title will be determined from the title in binder or from the title prefix and suffix settings you have determined in the “Formatting” pane (“Section Layout”) and in “Title Adjustments”.

All the best,

Thanks - but I know all of that. And I used to be able to make it work. Now I can’t. It will not work the way it should.

Further to my previous post - I’m now semi-convinced something has changed in Scrivener’s behaviour with regards table of contents with the latest update. When I reload previously compiled versions of a book saved on my hard disk, it displays with “Chapter - number - name of chapter”. Which is what I want. It does this in both the page of contents at the start and the running contents down the side of the Kindle Mac app.

But when I recompile the book as .mobi and open it in Kindle, there is no “chapter” or the number. There is only the name of the chapter.

Nothing has changed on the Scrivener file. The only thing that has changed is the app itself. I think.

Anyone else experienced anything similar?

Okay, so I did some more testing. And the results are in…

I tried opening files in Calibre, in case it was the Kindle app on mac messing things up. But my old files saved on my hard drive had the table of contents working fine. New .mobi files created from UNCHANGED scrivener docs did not have a the word “chapter” or the chapter number.

So I cracked open Time Machine and did a roll back to Scrivener 2.2. And now when I do a compile from the same Scriv doc, the table of contents is created properly. Everything works fine in both Calibre and

So, if you’re having problems with your table of contents, try a roll-back to 2.2.

Keith - I have no idea how this could happen, I’m not the kind of person who can create or trouble shoot applications. But that’s my experience. It might be worth checking to see if you can replicate it.

I can’t replicate it, so please can you send me a zipped up version of your project to AT literatureandlatte DOT com so that I can see the problem in your project for myself?

I don’t recommend anyone roll back to 2.2 as a lot of bugs have been fixed since then.

Will do

Okay, I take back the bit about rolling back to 2.2. Keith has sorted it for me - and the bug was actually in 2.2, sorted in 2.3, but I had found work arounds to the bug through trial and error in 2.2, and hadn’t changed them.

Thanks for sending the file, by the way, Simon - I’m glad we got to the bottom of it!
All the best,