There’s actually a simple reason your Second Life viewer messes up when you’re taking a snapshot. I’ve covered it in a number of places at various times, but as the information doesn’t seem to be widespread, it seems to be worth repeating.
There are three particular circumstances where the Second Life viewer is unable to communicate with the Second Life grid and servers or indeed with anything else.
The first is when the application is actively reading and writing to the disk.
The second is when the file-selector dialog is open.
The third is when the CPU is jammed up in a tight, heavy-duty calculation.
During all three of these, the effect as far as communications go is the same as if you had unplugged your network cable, then plugged it back in again. The application is simply unable to communicate, and can neither make requests from the servers, nor reply to any server messages. Any communications sent to the viewer by the servers during that time is likely lost.
Normally, there’s not a lot of time spent either reading/writing the disk, or doing calculations. A fraction of a second goes by, maybe a packet gets lost, maybe not. Nobody really notices. But there are times it gets more serious.
Assembling, processing and saving a snapshot is one of those times. And it goes more than double for hi-res snapshots.
Take and save a snapshot and keep an eye on your hard-drive activity light. See how it goes a little nuts there? Mind how long it lasts. Also keep a rough count of the time you spend in the file-selector. If you pass 15 seconds, you’re in increasing amounts of trouble. Combine both together, and it’s like you’ve pulled the network cable out of your computer for that long (or turned off your Wireless Access Point).
Lose connection for too long, and at best, a communications circuit will break. What’s commonly referred to as “redmapped” (because the minimap shows simulators that the viewer cannot communicate with shaded in red). As soon as the viewer notices that the communications are messed up, you’ll get the message that you’ve been disconnected.
As a bonus, there’s a bug in the texture-downloading/decoding pipeline, where an interrupted texture download can appear to be ‘done’, but there’s not enough of it to keep, so the downloader throws it away, but the decoder jumps in to try to decode it, and it isn’t there. That causes the viewer to crash. (There’s a prototype fix for this in the works)
Hi-res snapshots are worse, because they take 20 or more times the amount of calculation, and as much more time writing to the disk. That drastically increases the odds of the communications interruption between the server and the viewer being a permanent one.
What can you do?
Turn your network bandwidth slider down under EDIT > PREFERENCES > NETWORK. The lower that is the less likely the temporary disruption is to cause a communications breakdown. Problem is that it can take a couple of minutes for the new setting to settle down properly. It’s not something you want to twiddle all the darn time.
Defrag your hard-drive! Wading through the filesystem looking for free-blocks is a low-level system/driver task. Save your system the effort and defrag the drive that you use to save snapshots. Even better, use a different drive to your main-use one. If you want a great Windows defragger, grab JKDefrag. It’s tiny, efficient and pretty darn fast.
Kill a few of your memory/CPU hog applications before taking screenshots. You don’t really want them competing for resources when you want your viewer to get through this task as quickly as possible. Do you really need to have it checking your email right now?
Get a faster CPU. Faster CPU = win. Don’t get one of those nasty Celeron things. They don’t perform as well as you might think from the other specifications.
Improve your disk throughput. SATA, or SATA2. Or an IDE drive not on the same cable as another drive you are heavily using at the same time. High-performance rates are important. If your computer needs to write a whole lot of data in one go (like a snapshot) it has to wait around while the drive receives that data and scribbles it onto the disk. Higher-performance means less time wasted by your system waiting for the drive to keep up.
Whew. There you have it. Any questions?