Binder Research folder hangs most times I deal with it.

[dbc183c7]

With 14 days left on trial, I'm still struggling with Scrivener's apparent inability to deal smoothly with a test project that has a low approximation -- 31 MB -- of the self-generated text I intend for it:
~ 50 MB + perhaps a score related low/mid-resolution images (neither of which I've read in posts et al. as said to amount to 'too much' stuff for individual projects) and
My actual intended single-project 'research' of about two GBs of PDF.
(The test text itself was imported and delimiter-split into documents, and is about equally roughly divided among two folders; two test pics & the two, large/small, PDFs were click-dragged in.
Trash has the most elsewise in it.)

The issue is that,
When I keyboard navigate (arrow up/down) to the Binder's top-level Research folder from the (currently placeholding) Draft folder, it takes several countable, tedious, seconds to simply get by Research to (not into) its two closed principal containers of test data,
the first, 'Thoughts', itself then takes 15+ sec. to get by, and
the second, 'Reference Texts & Quotes', 20+.
(In all three cases, Scrivener is 'not responding' during the wait. Once opened during a session, Scrivener does respond quicker, sometimes 'pleasantly' so , but mostly only about 50-60% more quickly.)

Mostly, it seems that the 'pause' is a result of Scrivening-rendering -- even when the folders are closed. In comparison, my current 'outliner', up/down is qualitatively as quick as Windows Explorer in similar operation.

And occasionally, Scrivener actually closes itself ... spontaneously ... as I click or move out of or into Research. ('Occasionally'; however, it did it again today as I moved from an empty folder in the minimalist Draft of two folders, moved to Research.)

Details will follow as requested, as they suggest themselves as relevant. I have totally uninstalled (USING CCleaner and Regedit), rebooted, reinstalled -- with Norton off -- to no advantage. As the saying goes, otherwise and elsewhere, apps (Word, the outliner, Chrome, BibleWorks, Logos ...) run stably and respond as they 'always' have for this computer -- even most together.

(I do understand that the PDFs may tax the app and may need to be handled differently, along the lines I handle them separately now, copying only specific text*. But I had been hoping for a bit more integration and a few saved steps, input and contextual review.
But that is for another time -- a data size comparable to those PDFs is not involved here.
*Aside: As does Nota Bene, it would be nice to have a 'tool' to use that strips PDFs' (and email's) hard breaks/returns from selected pasted editor window text.)

I really do want to move to Scrivener. Yet, when I encountered this same condition in late 2014, I decided then to watch/wait a bit, and not buy Scrivener. I still want Scrivener: It checks all the boxes (and more) that I was looking for to step up from my current robust outliner (which is getting long in the tooth and it's more recent version has turned away from my use of it).

[Linus]

I had experienced the same problems, but then accidentally came across a solution which improved things for me. No idea why though. Maybe it will do for you as well:

http://www.literatureandlatte.com/forum/viewtopic.php?f=32&t=33821#p210866

[SpringfieldMH]

"SCRIVENINGS" VIEW MODE CONSIDERATIONS

Every item in the binder, regardless of whether currently presenting as a folder or document item, can have it's own text associated with it and can contain subordinate items (folders and documents).

Some of the delays, particularly if they get longer in direct relation to the number of items and/or amount of material contained in the delaying item, are likely due to a containing item (typically a folder) having last been viewed in scrivenings (concatenated/multi-item) mode rather than single (just-the-current) item mode.

This gets set and remembered for each item on an ongoing basis by how the user last opted to view each folder item (original default is to only show text associated with the containing item itself, rather than that plus all the text associated with all subordinate folders and document items contained within the folder).

This can be toggled between scrivenings view and single item view via the "View the group's subdocuments as scrivenings" button just to the left of the corkboard button top center of the screen.

If one clicks on or keyboard navigates to the Research folder and it was last viewed in scrivenings mode, Scrivener is going to proceed to open every subfolder and document item contained within Research, in order to present the scrivenings view. Basically, if navigating linearly up from below Research, depending on how it and its subfolders have previously been viewed, you can experience a significant delay as it opens everything inside each primary subfolder and then an even longer cumulative delay when it opens all those as part of Research.

Toggle scrivenings view off for Research (i.e. while clicked on it) or any other item containing subordinate items and you'll experience markedly faster response next time you navigate to or click on same. This holds true regardless of whether Research or other containing item itself or its subordinate items are closed or expanded in the binder view. Same holds true for the Draft (Manuscript) folder, if it contains much material/numerous items.

Basically, work out how you prefer to deal with this. Can toggle high level all-containing folders to single rather than scrivenings view and/or jump (click) directly to low level less-containing items, to avoid the greater delays associated with higher level items.

I work on an 8 core 4GHz system with 16GB of RAM and a high speed hard drive and I still make it a point to not click on the high level Research or Draft themselves unless I really really want to. I can see as much or little of the hierarchy in the binder as I want, without invoking that penalty.


OTHER ODDS AND ENDS

Assure a reasonable amount of free RAM (chip memory) and hard drive space.

Using a pointing device (mouse, touchpad, etc.) to jump directly to a desired folder or item within a folder, rather than using the keyboard to navigate there linearly through other material, will avoid some folders/items and related delays.

The Research folder can be moved within the Project, to above the Draft folder, such that if navigating from Draft to a subfolder in Research, will encounter the subfolder before reaching the main Research folder.

Numerous images within a single document can result in sluggishness when attempting to edit that document. I don't recall if it has much affect when viewing multiple documents in scrivenings (concatenated/multi-document) mode.



Hope that helps.

[dbc183c7]

Thank you Linus;
My session start-ups understandably remain slow when I leave a scrivening in an editor at shutdown. However, my concern had to deal with my routine navigation of the binder via the keyboard when the binder's 'folders' are closed: As it was, I found it -- disruptive -- as I collate/weave thoughts among documents.
(My current draft composing app, a robust outliner, displays individual notes (documents) mostly only when they're selected, and then it displays as much of it and as many others around it as fit its similar LOOKING editor window.)

Thanks for your suggestion and effort.

And thank you Springfield ...
Your 'toggling scrivening off' did the trick.
I understand now that some time ago, I had gotten (the suggestion of) the same answer, but your response here pointed (and educated) me whither I needed to 'see'.
(In that earlier post, there was also a reference to the next major update's allowing for the setting of container defaults for this --
Which I think means that whatever I do to a container in one session re scrivenings, the next session will 'forget' about it, and apply the default. We'll see.)

Re "Numerous images within a single document can result in sluggishness" ...
Yes, understandably; the same is true for my outliner with various embedded charts, graphs, pics.

(I had already composed my response to Linus before I saw your post 'at the last minute': I abbreviated that a great deal now, throwing out a great deal of my now-outdated supposings, some on point, others not.)

Thanks again for your responses ... both of you.
What a relief!

> Follow-on notes: The larger of the two Research folders has ~ 885k words.
> After yesterday's reinstall (and reopening a self-closed Scrivener), S. lost contact with Windows' file management -- File > Open/Save As ... did nothing.
I downloaded another 1.9.0 copy*, uninstalled yesterday's installation, installed the download ... and so far, 'File' works & there have been no spontaneous Scrivener Exits.

*Which I really don't think made a difference: Another reinstall with the file I had probably would have 'fixed' the File issue. (Session restart did not; maybe a system bounce?)

[dbc183c7]

Springfield,
Is there an obvious visual queue that tells me the scrivening status of a selected binder container?
g

[SpringfieldMH]

See note at bottom re seeing section 5.2 View Modes in the manual, if the following doesn't make sense or turns out to be wrong.

For the currently selected binder item, I have noticed two indicators:

- The scrivenings button (left of the corkboard button at top center of the app) which employs a combination of multidocument vs single document icon and a white vs yellow color background.
It shows a multidocument icon if the currently selected item has subordinate items and a single document icon if not.
For a multidocument item, white background in the button's icon indicates are seeing only that item's associated text, yellow indicates that are seeing scrivenings (concatenated) view of it and all its subordinate items text. (The corkboard and outlining view mode buttons employ this same white vs yellow coloring, to indicate whether are viewing the text for just the currently selected item or the corkboard or outlining view of an item containing/having subordinate items.)

- In the edit window for that item (item having subordinate items, viewed in scrivening mode), the contents of that item and its subordinate items will be displayed one after the other, with a horizontal line (dashes or hyphens) separating them. Depending on the length of the items, one might possibly have to scroll up or down to see those dividers.

I was thinking that it remembered this viewing mode and associated color indication on a per item basis, but appears it goes with whichever was last used. See section 5.2 View Modes in the manual, which is available both inside Scrivener under Help and also as a PDF download here
http://literatureandlatte.com/support.php#Scrivener

Past discussion on the forums indicates that LIterature and Latte have tried different approaches to these buttons and representing states and this is what they've determined works best.

Hope that is of some assistance. I'm sure it can be said better than I have managed here.

[dbc183c7]

Hope that is of some assistance. I'm sure it can be said better than I have managed here.

Thank you. Whether 'can be said better' or not, it was gratefully enough for me.

I had stared at that button as I clicked it back and forth, I think mostly expecting it to go multi-/single-document image: For whatever reason I missed the color shift. (I've not tinkered with the color scheme of the download -- yet.)

Thanks,
george

[dbc183c7]

I accept that qualitatively, the hang (aka, very long response delay) has some to do with my 5-year old i5 PC chip and with my container organization of the data in Scrivener, and much to do with less-rather-than-more RAM state (8GB): Both the technical stuff will be addressed soon (the RAM likely trebling, likewise the swap file); the org. is already substantially so.

The only real issue on this hang business is when I nevertheless click wrongly (mostly, inadvertently 'scrivening' 100s of thousands of words) : Scrivener tends to shutdown on its own when it 'comes back', responds. (On restarting, the data has 'always' been retained; nothing's been lost.)

[dbc183c7]

I have found that the 'hang inconvenience' project size FOR ME is about 500 MB. But I am still making the transition to Scrivener: My building project * is already just short of 1 GB, most of which is unchanging reference material, either PDF or TXT. (I routinely take out the Trash. )
*Substantially constructed.

In my current situation, a project search with a new string is an occasion for going off to do something else, either physically or in other software. (Scrivener just now once more closed itself after completing its search: As noted elsewhere in such cases text changes are saved, due the default 2-second setting. However at least this time, window positioning, project-search setting (search TEXT), icon changes (from no-content document to containing), were not saved.)

Such hangs do not happen always, nor quite sporadically. They can lessen substantially after I stay in Scrivener for a bit: After about the third search, searches become useful as does scrivenings' displaying ~20k words. (Though a request to display 10x that many did just now close Scrivener again.)
But it doesn't take a lot of 'outside' activity to reset the hang potential: Copying a very large folder ... 400 MB ... from the working project to my research Stack project for instance.

There is a further restriction that I impose on my system: Chrome, with many tabs. This browser does have a reputation for using as much memory as it can get its 'hands' on, which may prompt a lot of swap file activity between it and Scrivener if I don't stay put in one or the other. (Though during today's testing, I've kept 'tabbing' to none.)
And I have two projects running, necessary if Scrivener cannot handle all my research info at once though that would make a cross-project search more important. (The editor settings of the second project can get lost too when Scrivener closes itself, not just those of the searched other project. For instance today, they were switched from corkboard to scrivenings.)

To be fair, what I already have in my new working project is ~ 8x more than I asked of my current, ageing, software : I was simply hoping I could pull my scattered research together for the sake of triggering greater serendipity. For the nonce, I will back out about 50% of that (merely click/dragging it to the second project -- thanks! ) in order to complete the transition of my actual work.

My intent for all this is less the reporting of a tech problem, more a progress report; I'll manage and continue transitioning, still expecting wonders when Win10 and the new hardware is in place. (I do appreciate Scrivener's potential for me.)

[dbc183c7]

A 'size' and usage (ie, PC environment) update.

I now have mostly separated my imported work and research into three principle projects:
My 'Core' project for my 20-odd Works In Project (WIPs); now about 300 MB, expected to be finally about 400 MB after I import everything from Info Select [infoselect] and Collection-condense it.
A 'Stack' of journals etc.; about 600 MB, expected to grow substantially.
A Stack of classic texts, sized from the Declaration of Independence to War and Peace; also about 600 MB, expected to grow more slowly than Journals.

I use Chrome aggressively, with many tabs open. (Chrome's separate-RAM-space-per-tab approach aides my tabiness.)
Chrome is usually among the first apps opened; Scrivener usually the last.
I think because of this sequence, when I do run a search, Scrivener/Windows spends a great deal of effort making room for S's indexing work, moving 'tabs' to the swap file. (I use about a quarter of them only during the day.)
Whatever the background reason, the first Scrivener search takes a make-a-cup-of-hot-chocolate amount of time ... or more ... to complete. (Sometimes, particularly with multiple projects open, Scrivener shuts down: I've not noticed any data loss or any project-organization corruption.)

(Does Scrivener build its project indices only when the first search is done? FOR ME -- because my Scrivener work will be perhaps more (re)search oriented than for many, I'd prefer that the (initial) indexing was done during the project's load, getting it done, out of the way.
Or even during the project's closing, with my project-closing backup. Were this final indexing done, besides being ready to go when the project opened, it might provide a (static) search dataset for 'search everything' cross-project searches )

All this changes (mostly) when I start Scrivener and do one search in the started project before I open Chrome. Not only is the initial search completed much more quickly -- with Scrivener even giving me time to finish typing my search string (provided I do that at pace) -- But subsequent inputs and searches happen closer still to 'instantly'. Even searches of a second, post-Chrome-started, project are often 'quick' from their get-go. (Searches for the third-started 600 MB project can seem to struggle for indexing elbow room.)

These thoughts are more cautionary encouragement than caveat. As noted elsewhere at least once, I accept that a faster processor, more RAM, Win10, will make a difference; as will my changed apps management. But I will say that the current machine's responses with the same Chrome (over) use and similar amounts of writing and texts in and outside of Info Select did not require the change.
Regardless, I am now otherwise comfortably working in Scrivener twice as much or more as in my 'old' app with only about half my WIPs across, and I look forward to being in S. full-time.