Opening Large File Errors

I am attempting to open a LARGE file created on the Mac on Windows (Version: 1.8.6.0 - 11 Mar 2015). The file is large enough that my friend (creator) of the file, cannot compile it into Mobi on his Mac. He mailed the files to me on a USB stick to see if my higher-powered PC can compile the files for him.

The file loads, but when I click on any folder, the application spins off into “Not Responding” or just crashes. Sometimes it reports “Not Responding” but after a minute or so it displays.

PC Specs:
Windows 8.1 Pro, 64-bit
Intel Core, i7-4770K @ 3.5 GHz
32GB RAM

The Task Manager reports that Scrivener is grabbing up to 1.3GB of memory.

The book is a combination of text and many photographs.

Any suggestions?

Thanks in advance,

-Alex

I’m rusty and not an expert, so take the following with a grain of salt. May include errors or fail to mention significant considerations…

If you’re trying to work on the Scrivener project while it is on the USB stick, copy it to your local hard drive and work on it there instead. Performance and reliability will most likely be significantly better.

Two major things that can slow Scrivener…

“Scrivening” view (combined/concatenated view of contents of multiple items within the currently selected folder item in the binder). This is a great feature, but can bog down on loading the multiple items if they are numerous (an entire novel consisting of lots of small documents) or contain images.

One workaround for projects on which you experience this, when using “scrivening” view, is to avoid clicking on high level folder items in the binder that contain lots of sub-items and instead work deeper in the binder hierarchy… down in subfolders or individual documents. On such large projects, best to select/view a low level item before saving/exiting, to avoid Scrivener attempting to load lots of items next time the project is opened.

Another workaround is to turn “scrivening” viewing off. This is done by clicking the “scrivening” button (located just to left of the corkboard and outlining buttons near the top of the Scrivener app). Doing so changes the view from the combining/concatenating “scrivening” view of contents of all documents in/subordinate to the selected item, to a view of only the current item. Clicking it again toggles back to “scrivenings” view. With “scrivening” view off, you’ll have to click on any individual item to see its contents.
Note that items can contain their own text/images… AND subordinate items. The common example would be folders, containing documents. This can result in a bit of panic, if one happens to click on a folder item which contains subordinate items (documents)… but not text/image itself, while not in “scrivenings” view, as the folder’s own local text may be empty. If in doubt, turn “scrivening” view back on or click on the subordinate items.
My naive interpretation is that all items in a Scrivener project actually consist of a single type of underlying multi-purpose item… that can contain both its own local text/images/properties AND subordinate items… and that items are typically made to look like folders vs. documents, etc. to show what they are likely being used for. (I.E. “document” items can contain subordinate items… and “folder” items can be changed to “document” items and vice versa, with no loss/change of properties and contents (I think)).

Within an individual document within a Scrivener project, multiple or high resolution images (and possibly really large amounts of text) can result in sluggishness/poor responsiveness when attempting to edit the document.

A fix for this is to split the document into multiple documents (which Scrivener can display concatenated together via its “scrivening” view and which Scrivener can compile out a single large product).

Another option is to use an image link in the document, that points to another location (elsewhere inside or outside of the project folder?). Upside is better performance while editing/viewing due to absence of image (gets included at compile time into the output). Downside is you don’t see the image while editing/viewing. (The Mac version of Scrivener also has an “image tag” feature that may do something similar, but that hasn’t apparently been brought over to the Windows version yet.)

You might try searching the forum on likely keyword combinations such as “multiple images” or “images slow” or “project size”, etc., to find various discussions related to this.

Hope the above is of some help.

Regarding “files”…

At the physical level in the Mac or Windows file systems, a Scrivener project is actually a folder, containing several subordinate sub-folders and many individual files. On Macs, this is hidden by the Mac operating system and the whole thing is presented as though it is a single thing (referred to as a “package” I believe). On Windows, this is not hidden.

So, a Scrivener project is not just a single simple file (even though Scrivener presents it as such inside Scrivener). Rather, it is (behind the scenes), a database comprised of many files.

Within Scrivener, when you open or navigate to a folder item that contains numerous sub-items (presented as sub-folders and documents, etc.), Scrivener has to open all those items, in order to present a combined/concatenated “scrivenings” view of them within a single view. If that is an entire work or sub-folder containing numerous/large items, it can take a while.

Regarding compiling projects that contain numerous/high resolution images (which I have little experience with)…

It will presumably take a while.

It may generate error/diagnostic messages indicating problems encountered. Such are hopefully displayed or written to a log file somewhere.

Depending on type of output desired, the images may be higher resolution than needed. If so, lower resolution versions of the images might result in faster/stabler compiles.

Other apps (Adobe InDesign?) may or may not be more appropriate for such photo intensive projects.

Again, hope that helps.

Thanks. Yes, I had copied the folder/files to my SSD drive. I wasn’t working from the USB (I know better).

I managed to split the document into single-chapter files. Each large chapter (4 chapters) and the Front Matter are in separate .scrivx files.

What I can’t figure out now is how to associate the multiple files to compile them into a single .mobi. I am familiar with the process in InDesign (a “book” file), but I can’t get them linked without reloading them into a master file (essentially undoing my chapter separation).

What obvious process am I missing? The manual doesn’t cover this option, or at least in an obvious manner.

The product output goal is a Kindle edition. InDesign’s Kindle output is poor at best (and I’m being overly generous). Unreadable is often more accurate. I’m not even certain why they bother to include the “feature.” Before I found Scrivener, I built and compiled eBooks by hand rather than use InDesign.

Thanks for the help.

-Alex

Anyone else, feel free to comment and advise Alex regarding this. I’m not that knowledgeable and may be misleading him.

I’ll try a little more, but run the risk of talking beyond what I know…

My sense is that you have split and saved the book into five separate Scrivener projects, presumably in the hope of greater responsiveness/stability within Scrivener due to the smaller project sizes.

I don’t know that there is a way to include/compile separate Scrivener projects into a single output (epub, mobi, etc.) via just the use of Scrivener. I was unable to find discussion of such via a quick search and am inclined to think the option doesn’t exist… but I have a vague memory of having seen it discussed some time ago here in the forums…

It does appear that through the use of additional free software (Calibre and/or Sigil), one can combine multiple epub files produced by Scrivener and convert/output the result as a mobi file. For information on this, fire up your favoriate search engine and search on things like “merge epub”. I don’t know how simple or complicated this might prove to be.

(A side note… One can compile all or only desired portions of a project in Scrivener (specified in the expanded Compile dialog). So, if a single massive project was resulting in lengthy/unstable compiles, one could presumably compile out portions and then combine them as discussed above.)

My naive sense is that I would keep the whole thing as a single Scrivener project… and then avoid sluggishness while editing by busting the chapters into multiple smaller subordinate documents (makes for more responsive editing and when compiled the chapters still present as a whole) and working/viewing down in the lower levels of the binder hierarchy (to avoid delays due to loading lots of documents for “scrivening” view).

That’s about all I can think to offer… other than to talk a bit more about Scrivener project file structure.

To revisit Scrivener project file structure, as it exists in the computer’s operating system’s file system (rather than how a project appears within Scrivener)…

A Scrivener project will appear in the file system as a folder with .scriv on the end of its name
(ex: ExampleScrivenerProject.scriv )
The project is that folder and everything in it, not just the project.scrivx file (see next paragraph). All the material within the project folder must be kept together and should be dealt with from within Scrivener (via opening and working on the project there) and rarely if ever at the operating system file system level (i.e. poking around in it via Windows Explorer, etc.).

Within that folder will be the Files, Settings and Snapshots sub-folders… and the project index file
(in Windows, usually named by default as project.scrivx)
which is basically a database index, in XML format, to the files comprising the project,
which reside in the ExampleScrivenerProject.scriv\Docs sub-folder.

On Macs, these file system details are hidden, via feature of the Mac OS (referred to as “packages” I believe), such that a Scrivener project presents as a single thing (at least unless one goes prowling the underlying hidden file system structure). As I recall, on Macs, the .scrivx index file may be named the same as the project
(ex: ExampleScrivenerProject.scrivx)
rather than project.scrivx and the Windows version of Scrivener can handle that.

If launching/opening a Scrivener project from the desktop/file system, rather than from inside Scrivener…
On a Mac, one does that via the single project “package” mentioned above.
On Windows, one does that via the .scrivx file inside the project’s .scriv folder.

Hope the above is of some assistance. Think I’ve now ventured beyond what I know and had best shut up. Perhaps others can chime in. Best of luck.

One more note…

Scrivener apparently launches Amazon’s KindleGen to accomplish a compile to mobi format.
For more info re KindleGen (or to download it (available for Mac, Windows, Linux)), see
amazon.com/gp/feature.html/?docId=1000765211

A standalone alternative is Amazon’s KindlePreviewer,
which accepts input in these formats (mobi, epub, azw, html, opf, prc, zip(XMDF)) and converts some or all of them (epub for certain) to mobi and lets you preview how they will appear on various Kindle models. Available for Mac and Windows.
It collects and reports warnings that occur during compile (see Compilation Details in the Compiling eBook screen that appears) and tells you where it puts the resulting mobi file (see “generated here” link in the Compiling eBook screen). Presumably could have Scrivener compile to epub, then run that through it.
amazon.com/gp/feature.html/r … 1000765211

Thanks for all of your input, SpringfieldMH.

Linking the images didn’t work. I think there are just too many and they are too high resolution. I spent hours pulling them and re-linking to no avail.

Scrivener for Windows is only a 32-bit application, which means it can only use up to around 2GB of memory, regardless of how much RAM I have in the box. I have been watching memory usage/allocation (Task Manager) and seen it hit 1.7GB. If it spike over 2GB, it can crash.

Even just clicking on a folder that holds the photos will cause Scrivener to freeze (“Not Responding”) for a bit until it comes back in 20-30 seconds. Even the “cork board” view will pause when clicking on a file/folder with the images.

My next step is to pull all of the photos out to see if it will still compile. If that works, I think my friend will just have to use smaller images. I read that the maximum image dimensions for iPad is 2048 x 1536.

It would be great is Scrivener would become available in 64-bit and be able to access more resources.

I am interested in this thread. I have similar issues related to hanging, “not responding” and such. My Projects are between a few kb to 1 GB and most of the time anything above a few MB Scrivener hangs.

The PC/Windows 64 Bit, 8GB RAM, 1TB HDD, NVidia Graphics Card and two monitors. (and there are no images or web sites or pages, everything is text).

Looking for more information, and, yes, I have untracked but lengthy time research on L&L Forum.

Also looking for things like “best practices” and optimal hardware and software conditions/requirements (not minimum requirements).

Thanks and happy sailing.

What I’ve wondered is whether when you realize you have just clicked on a high level folder in Scrivenings by mistake and start watching that ball go around if there’s a way to cancel the operation?