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?
Methinks LL needs to apply some multithreaded programming techniques to the viewer, which would help keep foreground dialogs and disk activity from b0rking the network communications…
It’s possible, certainly. In Windows, however, you have to work around the fact that the system is actually trying to prevent you from doing certain things while these operations are in progress.
As for stuff like the file-selector, actually making the file-selector run asynchronously to the rest of the application is a bit of a tougher job. Some stuff has to wait. Other stuff gets to go. What if the user forgets that it is there? What if they forget and try to upload/save something else?
It’s not insurmountable, but it is certainly a tricky thing to approach.
Great info, Tateru. I only wish my situation were so easy. For some reason, every time I try to do any file transfer via the viewer, be it saving a snapshot to my hard drive, uploading the snapshot to my inventory or uploading/downloading any texture, my viewer simply crashes. Just poof! It’s as if my system is simply killing the process. I’ve tried it with the standard SL viewer, the RC and the Cool Viewer. All the same. If I click, for instance, Save to Disk then “blink” it’s gone.
I’m running SL on an Acer tower with 4GB Ram, dual core Intel processor, loads of harddrive space and Vista as the OS. Could this be a firewall/anti-virus issue? I have Windows Firewall active and am using AVG antivirus.
Thanks for this, Tateru. This is about one’s personal interaction with the Grid, to be sure, but more people need to be mindful of all the behind-the-scenes activity that is involved in any Grid-interactive situation. Why? Because what you are doing, what you are wearing, what scripted objects you have running, basically everything you do (unless you are standing alone on an empty full-sim) is affecting everyone else’s experience.
@Onyx: I can’t speak to whether it has anything to do with Vista configuration (as I don’t use it–still XP), but I would second the thought that it is anti-virus related. I use McAffee myself. I used to have it set to automatic updates, and every time (and it was often) the software would go out and check for new updates SL would just lock up. Sometimes (rarely) crash, but this may have been less of a problem because my CPU is quad (not sure). Anyway, when I set it to manual updates the problem disappeared and the software reminds me periodically to go and check.
Oh, and I use the McAffee firewall and have the Windows one de-activated. Someone else may be able to comment if that makes a difference.
I’ve had it happen several times when browsing folders to find where the file i wanted to upload was
and it happens all the time with me during the login, the damn thing freezes at “Initiating multimedia” and when it starts responding again the login process was screwed up and I can’t login (seems I have bigger odds of managing to login if I try to login directly into an empty sim with no streams set, but the odds increase just very slightly), and before anyone say it, I already tried uninstalling and reinstalling Quicktime as well as trying with it uninstalled, and also tried QTAlternative, and several other SL clients I’ve tried have the same issue
Thanks, Tateru, but I think most problems nowdays come from the texture problemas. They are not fully loaded, and you can’t seem to force that in anyway.
As my desktop gets better, graphics card more powerfull and my internet link higher, all facts leads me to beleive that it was not my fault after all. My SL experience just decreases day by day.