I am trying to compile a Kindle eBook with the latest version of Scrivener on an M1 Mac. The book has a lot of photos, and a file size of about 700 MB, but it is taking forever to compile, and then usually fails. Mac Activity Monitor keeps showing Scrivener as Not Responding.
Making things worse, on eBook compile, other than the progress-bar which seems to stall at about 95 percent, it does not show any info on actually processing, other than the color wheel which also keeps stalling.
To some, 700 MB may seem large, but it is not, and these images are not huge files. This compiling issue needs to be fixed, and include indication of what the compiler is actually doing, like showing if it working on each image, or text so we have an idea what is causing the issue. Interestingly, I never had an issue on slow i3 Intel Mac with half the Ram, running an older version of Scrivener.
I bought my version of Scrivener directly from the website, and bought a Macbook to run it as the PC version crashes all the time, but now I am thinking of buying the software again from the app store, so I can leave truthful and factual feedback, so hopefully the author will fix these issue or loose sales, because for $50 this program should work. 40 minutes to fail a compile is ridiculous.
Do you have Linked Images instead of Embedded images? Linked images will reduce the file size of your project.
700mb is not a regular size for a book, even with many images. Scrivener is not design software, but writing software. You might consider importing your work in InDesign and adding those images there, which will be Linked images by default.
The images are linked. As for Scrivener, size should not matter as Scrivener cheats and uses small files for every entry in the binder, it is not much more advanced than Word pad or a very basic text editor with added spell checker, and most of the time the spell checker is crap. All Scrivener does then is stitch each of these files together to make a continuous file.
I found out the main issue Scrivener is having is when it finds an image file it does not like. If Scrivener was smart it would show the processing for each checked entry (and why does it not have a select / deselect all option) of the binder in the compile list, going down the list one at a time, then checking when it had done that item, or maybe writing completed. Instead it shows nothing, with little or no info to go by to find out what part is causing the issue.
When people go on about this being the best, oh if I was a coder I would make this look silly and give writers what they really want, instead of a partial baked product to make themselves a ton of money.
There is definitely something screwball with your setup/manuscript. 800MB is a very large file. My books Scrivener V3 for Mac and Win are both very image intensive, but nowhere near that size.
Apple give this program an 'Editor’s Choice’and the vast majority of feedback is 4-5 stars, plus the MANY MANY people on this forum and Facebook Scrivener groups rate it extremely highly - does that tell you anything?
Suggest before you mouth off about leaving bad (and underserved) feedback based on a total lack of understanding of the value and complexity of the program as evidenced by your second diatribe,‘oh if I was a coder’ clearly you are not and do not understand what has gone into this great program, reach out to L&L Support.
Everyone here and the L&L team will work with you to help sort your issue, but mouthing off uninformed rubbish and threatsof negative feedback doesn’t do much for your cause. (IMHO)
I made a website similar to this, but with a lot more options a long time ago, and that can compile a whole lot more info, and much faster, but only in PDF, and it is web based. So I know what is possible, and when the same issues do not get fixed on Scrivener even when numerous people complain about it, that is disappointing.
To the original poster, feel free to open a support ticket here:
As others have said, 700 MB is quite a large file, and the size does matter when you’re Compiling the document, as the whole point is to stitch the component documents together.
To other contributors to the thread, there’s no need to dive into the relative merits of Scrivener itself. We understand that Scrivener may not meet the needs of all writers, and encourage people to use whatever tools fit the tasks they want to accomplish.
I fully realize that Scrivener is not for everyone (never said it is) and I’ve seen and participated in civilised discussion with people who prefer other apps. I use others for specific needs.
I have a short fuse for those who threaten undeserved bad feedback for any developer’s work based on the fact that an otherwise excellent app is not best for their particular scenario or because of their incompetance.
As I said, there are people here, L&L staff included, who will go out of their way to help, but opening a request for help by throwing sh.t in all directions doesn’t strike me as the best way to encourage that help.
When compiling to Mobi, Scrivener first assembles all of the HTML files together into a temporary folder, and then passes the process off to KindleGen, which is found embedded in the Kindle Previewer tool. Once it does that, it simply waits until that process concludes before taking the file KindleGen generates and saves it to your designated output folder.
Overall I would not say that’s the best way to produce a large book that is causing issues, because it obscures where the problem really sits—for all we know KindleGen is running out of resources and halts, so Scrivener never gets the file back and just waits forever. What would probably be better is to compile to ePub format, which is entirely done within Scrivener. From there if you really need a Mobi document you can drop it into Kindle Previewer and wait. But do be aware Amazon no longer recommends Mobi files for anything, these days. It’s a bit of a legacy format. You’ll even get a warning message if you try to load a Mobi file in Kindle Previewer.
Thank you for that explanation, as I now have a much better idea of what is going on; more so as I know the Kindle software is Intel based, so it will have a huge hit on processing power on Apple Silicon.
I still hope that Scrivener can improve the way it displays the compiling process as I mentioned previously, and for things like this, simply say something like ‘Generating Kindle file’, '‘Transferring Kindle file to KindleGen’, ‘Waiting for file’ You know instead of seeing a spinning wheel of nothingness.
…more so as I know the Kindle software is Intel based, so it will have a huge hit on processing power on Apple Silicon.
Ah, that would make a pretty big difference in performance I’m sure. I’ll probably be waiting a few more years before I consider switching over for production work. It took a good long while for Intel to be as acceptable as PowerPC back in the day, too, with a few notable players taking a while to get their software up to speed.
Regarding whether this could be designed better, I’m sure it could be, but to be clear this is ordinarily something nobody runs into. For 99%, it takes about anywhere from a few seconds to under five minutes to compile a book, and the KindleGen component of that only takes a fraction of the total.
I’m not sure what the state of Calibre is yet in the M1 department, but one thing worth noting about it is that it is, among many other things, the best ebook file type conversion tool available. It supports dozens of formats, including the modern Amazon book formats. Unless you need a .mobi for an ancient Gen2 Kindle or something, the result you get from its .epub to .azw conversion will doubtlessly be superior (and I would say its .mobi conversion is probably better than Amazon’s as well, because it’s designed to make an ebook and not a KDP upload asset that KDP doesn’t recommend anymore—there is a fine difference between the two that results in book files twice as large as they should be). It will even recognise your device if you plug it in, and convert to the optimum format for it on the fly, if you drag a book into the device’s library.
As to the rest of this commentary and back-and-forth going on here, I would remind everyone of the forum policy to be polite to one another—and that includes toward us. Coming into a pub and loudly mouthing off about the service, food, owner, seats and glassware is only going to get the locals riled up, and probably will explain the lack of finer service you’d get otherwise, too. And that doesn’t excuse people getting riled up either, as I don’t see polite behaviour from up-stream here on that side, either.
I decided to try ePub for compiling, and it seems to work better. It still takes a long time even though it is not really pushing the M1, well memory usage was low during processing on this 16GB model. I guess the time it is taking is converting, maybe compressing the images. I then used Calibre for converting the ePub to Mobi which takes a while, but nowhere near as long as doing it directly in Scrivener.
I hope in a future update, the compiling can be made to show what is going on a line at a time. Processing, compressing, Complete… An example for this is I did find one image that Scrivener did not like for some reason. I then opened it in Mac Preview, deleted the original image, and resaved it, that then saved about 10 minutes in processing time. To find that file took many hours. If I could have seen the file as it was trying to compile, and seen it was taking much longer than all the rest, it would have been a quick easy fix.
Yes. I don’t necessarily disagree with any of that, and think a detailed logging of what is being done wouldn’t hurt anyone. I don’t know if that needs to be in the GUI itself, but there have certainly been times I’ve wished for better reporting somewhere.
On the matter of isolating a problematic spot in a large data set, here is a good method that works simply and efficiently: divide the data in half and test each independently. If half A works fine but half B does not, then you can dispense with that whole half of the work. Divide B and see whether B1 or B2 fails, and then B1a or B1b, and so on. Even in very large works, it should not take more than a half dozen at most divisions to isolate within a few images where the problem sits. It may still take half an hour, but it should never take hours of sifting through images one by one.