Jump to content

Tips and Tricks

  • entries
  • comments
  • views

Contributors to this blog

[QUICKTIP] Running multiple Viewers? Separate your cache folders!

Torley Linden


Running multiple Viewers has become more accessible thanks to an easy checkbox in Viewer 2.4 Beta.

If you run multiple Viewers (what are the official Viewers?) — for example, you prefer building in 1.23 but want 2.3's communication enhancements, and are also testing the Mesh project viewer — certain aspects can conflict, especially if you're running them at the same time.

For example, each Viewer refers to a cache folder which stores info about inventory, textures, sounds, and other previously-accessed data for quicker retrieval. Having a bunch of Viewers using the same cache folder is like a game of Hungry Hungry Hippos™* — they clash for resources OM NOM NOM and oddities like perceived inventory loss (never fun) and corrupt textures (that sucks too) may result.

However, you can change your cache location for each Viewer.

  1. On the Viewer's login screen, choose Me menu > Preferences. (In Viewer 1.23, it's Edit menu > Preferences.)
  2. In the PREFERENCES window, click Setup tab. (In Viewer 1.23, it's Network tab.)
  3. Click the Browse button. (In Viewer 1.23, it's the Set button.)
  4. Use the file browser to choose a different folder, or create a new one. Then choose it.
  5. Quit the Viewer (as changes won't happen until you restart it), then repeat the above for each Viewer.

PREFERENCES - Setup tab - Browse button to change cache location.png

Thanks to cheery Sylvan Mole of our Linden Department of Public Works for suggesting this tip!

What tips do you have for using multiple Viewers?

* The hippo analogy is even more funny when you realize hippos are SL's unofficial mascot.

  • Thanks 1


Recommended Comments

We have been advising people to do this for years. Here in these forums and elsewhere. What Emerald did was the correct approach to eliminate this defective viewer feature. Emerald installed it's cache to it's own unique directory. What LL needs to do is each viewer create it's own unique cache folder on install. Problem solved. The fact some TPVs have been doing this for a long time should tell LL something.

Link to comment

So what? making separate cache folders to prevent numerous issues predated Emerald's creation of it's own folder. And that was done immediately after I had a convo with the emerald developer about the need for each viewer to have it's own folder. Every viewer version written by whoever has issues with cache. If you think about it then you might see why.

LL needs to make all versions create their own cache folder. So do all TPVs. Problem solved. In the meantime we users have to manually accomodate this defect ourselves. Oh and how's that reset cache working out? You know the one. It resets cache location to default and you have to go manually delete the cache and go reset the cache location again and what happens is people wind up all using the default again. So yes LL needs to address this with a separate cache location on a by version basis. And not reset cache location on reset.


too many defects.

Link to comment


The issue with multiple instances of the same viewer is different, in that case the trouble is that only the first instance is given write access to the cache, the rest are read only if they do not get their own folders. The third party viewers share this limitation and Torley's advice applies to them too.

Torley's suggestion has zero to do with running multiple instances at the same time. There is no fix for that. it isn't even possible in a reliable manner. Maybe with a command line parm to load a different setting file for each instance you want to run. Eventually something hard coded to the default is still going to bite anyway.

Link to comment
  • user wants to run 4 sessions at once
  • user runs sl, sets cache to xyz1, logs to lxyz1, restarts client
  • user runs sl second time, sets cache to xyz2, logs to lxyz2, restarts client
  • user runs sl 3rd time, sets cache to xyz3, logs to lxyz3, restarts client
  • user runs sl 4th time, sets cache to xyz4, logs to lxyz4, restarts client
  • user gets done, closes sl clients
  • user loads sl client. cach now set to xyz4, logs to lxyz4

Is that about right?

I would recommend using separate configuration files and load them on the command line of the 4 sl client shortcuts. Otherwise there is still room for issues. And given what happens with cache/log settings under certain circumstances it might be wise to load a custom config on the command line all the time anyway.

Link to comment

I'm glad you gave this basic truism - different viewers each need their own cache - more visibility, Torley!

It would be ideal if something could be done along the lines of what Ann suggests - if the Linden codebase could contain a snippet that automagically appends a unique string to the standard cache name for each viewer.  Of course, that presupposes that each viewer has a numeric unique identifier, which perhaps requires more coordination than the TPV community could be expected to demonstrate.  You COULD hash the viewer name, but ... hmmm ... prolly lead to a proliferation of abandoned cache folders.  Ah well.

Link to comment

Cerise, Ann is right when she says when running multiple instances of the same viewer only the first instance gets write access to the texture cache. Let's have a look what happens in LLAppViewer::initCache() in llappviewer.cpp:

     BOOL read_only = mSecondInstance ? TRUE : FALSE;
     LLAppViewer::getTextureCache()->setReadOnly(read_only) ;

As we can see, the texture cache is set to read-only if you are running a second instance of the viewer. When I compile the viewer for myself, I always allow write access to the texture cache to all instances because I use different settings-files with different cache folders for each instance.

Link to comment

The issue with multiple instances of the same viewer is different, in that case the trouble is that only the first instance is given write access to the cache, the rest are read only if they do not get their own folders. The third party viewers share this limitation and Torley's advice applies to them too.

I was unaware that multiple instances of a viewer had read-only cache access, but I can see how it came to be.  This just causes a performance hit for viewers 2-n, rather than any errors, yes?

I'm wondering if Linden support has been seeing an increased volume of crash complaints due to cache incoherency, and that's why this hint is (finally) seeing the light of day.  I have suspicions that something has happened server-side that is leading to cache errors.  I've been using the same ancient viewer (Snowglobe 1.5x) since it was posted, and in the past - oh, two months? - I've begun getting intermittent series's of rapid crashes that are fixed by clearing cache.  I've seen friends encounter this on other viewers as well.


ETA: I'm seeing this on both of my machines, very different environments, one Win7, one XP, etc..  Never was a problem before a couple of months (or so) ago.  Goes away every time with a simple cache clear.

Link to comment

Hi torley,

You should also do this trick if you alternate between using Viewer 1.23.5 and LL V2.x.  Ditto v2.x and any of the other v1.x source code based viewers (Phoenix, Imprudence.. whatever).  Note that I am referring to alternating use, not concurrent use.

In addition, I recommend using the "--settings" command line option give every one of of your viewer programs distinct setting files.


Link to comment
  • Create New...