1.5.2, Snow Leopard, and Large Project Files

I have one very large project file–38.4 mb in size, hundreds of internal docs, many nested. I used this file everyday with 1.5.1 and Leopard.

Last night, I upgraded to Snow Leopard and 1.5.2. When I launched Scrivener, it gave me a warning that this large file (which it automatically opens) hadn’t been closed properly, and it said that it needed to synchronize the search strings. It took a while for that window to come up, then much longer for the project window to come up.

And then–spinning beachballs. For a long, long time. I let it sit and went to bed. This morning, the beachballs were gone, and Scrivener was responsive. Played around with the file, and all seemed well.

Until I quit Scrivener and reopened that file. Same problem (minus the search strings). As I type this, Scrivener has been beachballing for 15 minutes, using as much as 35 percent of the CPU, 1.31 gb real memory, and 2.18 virtual.

I tested Scrivener with smaller projects and had no problem whatsoever. It’s only this large project–representing almost three years of work, of course :smiley: --that is causing Scrivener to choke.

I’ve run a sample of Scrivener and attached that. Please let me know if there’s anything else I can do to help you diagnose the problem.
Sample of Scrivener Opening Large Project.txt (5.11 KB)

Hi,

Sorry you’re having problems. Unfortunately the sample doesn’t give any specific Scrivener methods that throw up anything obvious.

A couple of things to try to start with:

• Try trashing your preferences file at ~/Library/Preferences/com.literatureandlatte.scrivener.plist (you will need to re-enter your licence details after doing this).

• Then ctrl-click on your project in the Finder and select “Show Package Contents”. Delete the file inside the package entitled ui.xml (note that you will get the synchronising search strings message again when opening, so there will be that delay the next time you open).

• Now launch Scrivener, enter your licence details and leave it for the search strings to activate.

• When that has finished, quit Scrivener and restart your computer, to clear out the memory completely.

• When your computer has restarted, ensure that nothing else is running on your computer, including any programs such as Typinator or TextExpander that run in the background. Then launch Scrivener.

At this point, Scrivener is a fresh state. If it still has problems, I’ll need to take a look at the project, I’m afraid (38MB isn’t actually that large, so I’m very surprised you’re having this problem; the Scrivener project I use to keep track of development is over 120MB and runs fast as anything… So something is clearly amiss here). What machine are you using?

Thanks and all the best,
Keith

Just for comparison, I opened Scriv and downloaded the upgrade to 1.5.2 a few minutes ago. I haven’t as yet installed SnowLeopard. My big file is 48.3 MB, and I have it also set to open automatically when Scriv launches. I closed it before I upgraded. When I relaunched Scriv 1.5.2, and opened the big project, I did get the Synchronising Search Strings window and beachball, but only for a minute or two, and then all was well. I closed the project, closed Scriv, relaunched, reopened the project and had no problem.

Again, SnowLeopard is not yet part of this mix.

Hope you find out what’s at the bottom of the glitch. I’ll update if I have any problems after installing SnowLeopard, when it arrives.

Bad news, Keith. I’ve done all that you’ve suggested, and it’s still not working. I’m on a 24" iMac.

My file may be triggering the problem, but it’s definitely related to 1.5.2. I copied my file to my MacBook Air, which is running Snow Leopard but still had Scrivener 1.5.1 on it. Scrivener 1.5.1 opened the file, synchronized the search strings, and everything was good to go.

I closed the file and reopened several times; it opened immediately.

I then updated the MacBook Air to Scrivener 1.5.2, and now the Air has the exact same problem.

Hi,

I find it really difficult to imagine how 1.52 could cause this in any way, as it is almost identical to 1.51. The internal changes are negligible - nothing has changed to the saving or opening methods.

But this always happens on startup? And after the program has launched, everything works fine? I wonder if it’s eSellerate’s checks, but I doubt it… Did you activate successfully? Could you please zip up the file and send it to me at support AT literatureandlatte DOT com. I know it’s large, so I hope you have a good internet connection. :slight_smile:

Thanks and all the best,
Keith

It always happens when I open that particular file, even if I keep Scrivener running, close the file, and reopen it. But on 1.5.1, I can close the file, reopen it, and have it ready to go almost immediately.

After opening the file, Scrivener grabs about 100 mb of real memory per second, until it tops out at about 1.4 gb real memory. Then it hangs there for a long, long time (usually an hour or more), until the project becomes available, and real memory drops back down to 60 mb or so.

So it’s probably not eSellerate’s check. I was able to activate successfully on both the iMac and the MacBook Air.

I’ve zipped the file and am sending it to you.

Hi all,

I just upgraded to Snow Leopard from Tiger, and am experiencing similar problems with one large project (38 or so mb) and a small one with lots of pdfs and web links (2.2mb). Whenever I try to open either of these two projects I get beachballed indefinitely and eventually have to force quit. I never had this problem in Tiger, so I suspect it has something to do with the new OS…

I have a black 13" MacBook (2.16ghz, 1gb RAM), purchased in September 2007.

Hopefully we can work something out!

-Marc

Hi,

Have you updated to 1.53 (the most recent update - actually listed as 1.52/1.53 in Finder’s Get Info, but as 1.53 in Scrivener’s own About box)? There was a bug in 1.52 where it could spend way too much time scanning through internal project files looking for files that don’t belong there, but this should have been fixed again in 1.53.

All the best,
Keith