Tips and Tricks

Thank you Torrey that was most clear and helpful.

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.

That's a really useful advice, Torley, thanks for sharing it! and Merry Christmas!!!

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.

...

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.

• 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.

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.

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.

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.

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.

dayse/da/mona