It seems as if since I have a bigger document (with images) in the binder Scrivener periodically (may be each 10 seconds or so) freezes all the time:
How could one avoid that?
If the issue is autosave (you should be able to test that) which seems likely as you are suggesting the problem increases as the size of the document increases.
- Insert links to images instead of inserting the image itself.
- Break up document into smaller sections
- Increase time between autosaves
- Increase the speed of the media you are saving to, reducing the time it takes to make the autosave.
- Reduce the file size of the images
- Keep text and images in separate documents in the binder. Scrivener only autosaves the active document you are writing in, not documents that haven’t changed since the last autosave a few seconds ago.
Many thanks.
Well, it appeared at least at the same time, if I see it right. When I set this to 60 seconds nothing changes, same behavior:
- Actually I want the images and text, information to be in the same place and I do not want to open each image separatly to see it.
- If the content does not give a reason I wouldn’t like to do it (only because of the technical need)
- I did without success and I want that period to be quite short.
- It is an SSD and it is an external USB 3.0 drive, no (useful) way to make them faster, I guess
- I assume, they cannot get any smaller (without causing disadvanteages)
So split content which belongs together? I am not sure.
So it does not save the entire project when autosaving. Actually saving a 10, 15 MB file shouldn’t cause such an effect then.
Many thanks again
Are you keeping the live active project on external usb drive? That is probably the reason. And is bound to create problems at some point.
Splitting the text in separate documents doesn’t mean you can’t see them together. Simply click on both in the binder, Scrivenings mode.
Yes, I do, Scrivener runs on the SSD. I once had tried storing the project(s) on the SSD, but I hadn’t found any difference.
Why?
Yes, that is right of course. But it appears a bit inconvenient (besides of the structure adapted to technical needs) and I am not quite sure how to do it. So each text / paragraph with an image would need two new documents, for the text and for that image and so on. Or, do you mean one doc for the text, one for the images?
And each time you want to see the text and images you would have to use the Scrivenings mode, mark the different docs, if I see it right.
Reading and writing over usb is never as fast as using the internal storage.
I would have the text in one document, then the image in it’s own, next piece of text in the next, and so on. Or actually, I wouldn’t have the images in the text at all. I keep them in the Research area until everything is finished. I split the efitor and show the image in the lower part and the text above. Makes it super easy to write.
Scrivener is primarily constructed for handling text. It’s not MS Word, where you need to have it all in one loooong file.
Depending on the output format I include images before compiling, or not. It depends on the output format, and where to the text is going to be sent.
Alright, thank you very much!
Do you include each image manually or automatically? So do you havve to add each image manually to the place you want it or automatically all of those images in a single procedure?
One at a time. It all depends on what I am publishing.
That is not necessarily true, as long as we’re talking modern SSDs and USB 3.0 interfaces. Depending on block sizes and amount of I/O requests, small saves like what Scrivener is doing (even with 10-15MB images in a document) is unlikely to be causing enough I/O traffic to come anywhere close to causing a bottleneck.
What is more likely to be a cause of slow-down on a modern Windows system is that the USB drive is, by default, set up within Windows to appear as a removable drive. This slows down file access (particularly writes) because Windows is trying to make sure that the least amount of corruption can happen if the drive is suddenly ejected/removed from the system. It does this by disabling any write caching that may be available for that drive.
If the drive is re-configured, you can remove the slowdown effect get better performance by enabling write caching. The downside is that you need to be VERY scrupulous about ejecting the drive and removing it safely to avoid corrupting your drive and data.
Here’s how it looks on Windows 10:
The structure of your Scrivener project doesn’t need to have any relationship to the final structure of your document if you don’t want it to – that’s what Compile is for. Breaking things up into multiple docs for technical reasons is a perfectly valid way to organize the project.
You can use low-res small images in your documents as you’re writing the draft, and then replace them with the higher-quality images just before your final compile.
You can break images and text into separate documents as Lunk suggests. You can even play with folder/document structure so that anything you break out like that is in its own level that Compile knows to simply stitch back together without separators, etc.
Using Scrivening mode is easy – just click on the parent folder of all the sibling documents. You don’t even need to multi-select them.
Many thanks for the scrennshots. Yes, that is why I have turned that option off (if it was not the default setting, but I assume it was) for all of my external drives. I have extremely big problems to remove a drive “safely” (I try to do it although that option is switched off), usually it does not work with me. And when the Notebook crashes, freezes, does not react the chance is better to not to lose data.
Yes, I meant the structure of the working area, the structure you have while writing not the final one. I need / want a special order of the working area.
But replacing them later manually sounds like an effort not being necessary, why not use the right images from the beginning?
Yes, yes, I use it a lot, didn’t know (anymore) that this is called Scrivening mode. But this Scrivening mode causes the same behavior I have with that “big” document at the moment.
You have received a lot of advice on alternatives to solve your problem. If none of them suits you, you will have to come up with solutions yourself. There are always technical restraints and you have to accept them and adapt to them.
Good luck with your writing.
Thank you very much, lunk!
If I am just repeating from other people forgive me. It is possible that I just don’t understand. But, here’s how I organize my document pictures:
under the pictures folder I have the scrivener project (for pictures only) - as
pictures/particular scrivener project’s images
All pictures for that project are in that folder. As things shape up, I change the names from descriptive to positional, so the third picture in chapter 5 becomes 5_03.jpg
Instead of inserting the pictures in the documents. I insert the link to the pictures. You cannot see the difference. the picture appears in the document exactly as it would if I inserted the picture into the document. Exactly the same. If I find a better picture, or resize the picture etc. then I can change it in the pictures folder with a graphics editor, and it will automatically change (after restart) in Scrivener.
In terms of whether the images will look worse if you resize them, that depends on what you are writing for. What media will they appear in and how big are they going to be in the final form? When I’m producing for the web, or for a pdf file, I reduce the size of the image to fit properly where it is going to go. So for example, if an image will go on the left of the first paragraph of a story on the web with the paragraph wrapping around it, then I may want the image to be 250 pixels wide, even if the original was 2048 pixels wide, so my image might only be 20K which is correct for that purpose and quick to download. On the other hand, if it is going to print, say for a brochure, you might want a lossless tiff file that is 500 MB or more for the graphics artists to deal with.
For what it is worth, I would not put either scrivener or the data or the original autosave on an external usb drive. I’d have all those local inside the computer. The backups Scrivener makes and the backups I make would go both on an external usb drive (or NAS), and also another backup into the cloud. - So original and original autosave inside computer. Backups to external local drive. another backup to cloud. Then periodic images of whole computer.
Why does Windows show you thumbnails of your pictures instead of the full picture in Explorer?
Performance.
While you’re working in and out of the documents in your project, having a low-res image helps keep down file size (and memory) and makes any sort of operations you have to perform snappier. It’s not that much work to replace them later – you can do it as you’re stepping through your pre-compile checklist, making sure that the image and caption match, the image is sized correctly, that you don’t need to zoom/crop to focus on a specific item, etc.
If you don’t want to do it, that’s fine, nothing says you have to – but remember TANSTAAFL*. Applications are a series of design assumptions, choices, and compromises; if you know what those are and work with them you’ll have an easier time than if you work against them. In this case, one of the choices for Scrivener is that multiple small files work better. The situation might get better when Scrivener 3 comes out given the switch to a newer underlying framework (my understanding is that Qt4’s text editors impose some limitations that affect how performant scrivening mode can be compared to MacOS and that they MAY be solved in Qt5) and extensive rewriting, or it might not. Whether or not you want to restructure your workflow is up to you, but you might want to invest a bit of time in playing around with a test project to at least SEE if any of the suggestions we’ve made help you enough to be worth the effort of changing your workflow.
Yes, a very good approach, thank you. I will try to to adapt my workflow to the best of my ability.
Many thanks again
Alright, sounds very good, I will try to make it work for me, thank you very much