Stuck at Initializing Texture Cache - Was working great right before restart for updates

[lolashwrites]

This is kind of frustrating. I have a great computer, optimal for gaming, and it was working perfectly. Until I restart it for anti-virus updates today like I do basically every week. After it turns back on I go to start up Firestorm Viewer and, oh look, it's stuck at "Initializing Texture Cache" at which point it becomes unresponsive. So ok, I try Second Life Viewer. Same thing. And it was working fine right before the update.

So...this is where you guys come in. What do I do?? I've heard of the clean re-install. Yeah ok I'll try that but it doesn't seem to work on a lot of people and I had this issue before with my old laptop and it didn't work then, so I don't have a lot of faith in that. Any other suggestions?

I also tried deleting everything in the texture cache.

Computer Specs:

ASUS G750J with Intel Quad Core i7, 16GB RAM, Windows 8, AVG Anti-virus and Nvidia GeForceGTX 765M

[lolashwrites]

Cancel this. 

For anyone with this similar issue:

I did a clean re-install by uninstalling both Firestorm Viewer and Second Life Viewer and any associated folders on my hard drive. While doing that, I also updated the driver for my graphics card online. I then re-installed Firestorm Viewer and at first it did freeze on Initializing Texture Cache again but it proceeded to open the viewer which allowed me to log on.

I'm not quite sure which one made it work but that's what I did and it worked for me.

[BrookeRanger]

I am having this problem and it is not being resolved by uninstalling and reinstalling. It happened suddenly. Any remedy?

[Henri Beauchamp]

On 1/8/2015 at 5:48 AM, lolashwrites said:

This is kind of frustrating. I have a great computer, optimal for gaming, and it was working perfectly. Until I restart it for anti-virus updates today like I do basically every week. After it turns back on I go to start up Firestorm Viewer and, oh look, it's stuck at ”Initializing Texture Cache” at which point it becomes unresponsive. So ok, I try Second Life Viewer. Same thing.

Cool VL Viewer sources: linden/indra/llfilesystem/lldiskcache.cpp file, read the comment for my code's Windoze exception:

	if (sCacheValid)
	{
#if LL_WINDOWS
		if (!second_instance)
		{
			// Do not call cacheDirSize() on startup from the main thread under
			// Windows when the cache directory has not already been scanned
			// (i.e. after boot, from the first viewer instance): it causes
			// minutes-long delays for large caches on hard disks (obviously a
			// problem with ”SuperFetch”, but even after disabling it, scanning
			// the cache can take a couple dozens seconds, when the same cache
			// takes at most a few seconds to get scanned under Linux) !
			// LLDiskCache::threadedPurge() will instead set sCurrentSizeBytes
			// for us, and in a non-blocking thread... HB
			llinfos << ”Nominal cache size: ” << sNominalSizeBytes
					<< ” bytes. Maximal cache size: ” << sMaxSizeBytes
					<< ” bytes. Cache directory: ” << sCacheDir << llendl;
			return;
		}
#endif
		sCurrentSizeBytes = cacheDirSize();
		llinfos << ”Nominal cache size: ” << sNominalSizeBytes
				<< ” bytes. Maximal cache size: ” << sMaxSizeBytes
				<< ” bytes. Current cache size: ” << sCurrentSizeBytes
				<< ” bytes. Cache directory: ” << sCacheDir << llendl;
	}

 

Excerpt from a months old public Open Source meeting (held, monthly, now), where I reported this issue:

Quote

Henri Beauchamp: I hope you solved the issue of the hyper-slow asset cache scanning occurring when starting the viewer just after a Windows reboot... Windows is so lame that it takes about 2-3 minutes to scan a 400Mb asset cache where Linux only needs 2-3 seconds !... I worked around the issue by threading the asset cache scanning...
Vir Linden: Don't know about that one Henri. Is there a JIRA? Could be we're fighting with windows for file system access
Beq Janus: also depends on what cache system
Henri Beauchamp: I saw some people complaining about the slow start of the lastest Firestorm under WIndows after a reboot too... and since the latter is using the new asset cache, I won't be surprise it got the same issue.
Beq Janus: I think you've dropped plans to rollout the non-VFS cache or at least put them on hold
Henri Beauchamp: No JIRA initiated by me... SInce I solved it for my viewer. :-P
Beq Janus: I don't see that dely and I've not seen a Jira
Henri Beauchamp: The non-VFS cache works great for me. It's just Windows file system being brain dead... If you got a SSD you are fine, but on a DD...
Vir Linden: We don't usually test specifically for running SL right after a reboot - normally we're looking at machines in a steady state
Beq Janus: ours has some threading in it in any case, has done since before the new version, not sure where abouts, not looked at it in a while
Henri Beauchamp: @Vir. Well, you should...

Thing is, most people rarely ever cold-boot every day: they prefer ”sleeping” their 'puter...

Edited September 20, 2022 by Henri Beauchamp

[Love Zhaoying]

1 hour ago, Henri Beauchamp said:

Thing is, most people rarely ever cold-boot every day: they prefer ”sleeping” their 'puter...

That's interesting, I power-down / restart my potato every time because, it wakes up from sleep in the middle of the night, then its fan wakes ME up from sleep!

I hadn't noticed any texture cache loading issues.  I'm not using the SSD, either (despite installing one years ago for the express purpose of SL caching).  Maybe I'm just lucky, or don't have a lot of cache..

[FlightlessAngel]

I have also had this problem and have found that a clean uninstall of ALL viewers installed on the PC and reinstall will fix it...however it seems to keep happening. Sometimes it will go a couple of months without needing an uninstall sometimes it does it a couple of times in a day, I'd really like to know what is triggering it so I can fix it.

[Bragon Zuhal]

I had this problem with Firestorm on Windows 11. First start after install worked, subsequent starts got stuck on "initializing texture cache" with the viewer showing a white screen. Deleting the Firestorm_x64 directories under AppData Roaming and Local would resolve it for one restart, but then the problem returns. Excluding the "C:\Users\uwe\AppData\Roaming\Firestorm_x64" folder from anti virus real-time protection solved the issue permanently.

[rebroad Xi]

Come on Linden Labs... this has been an ongoing issue for at least 12 years now. Why is it taking so long to fix?!

[Aishagain]

6 hours ago, rebroad Xi said:

Come on Linden Labs... this has been an ongoing issue for at least 12 years now. Why is it taking so long to fix?!

Possibly because it's not their problem to fix!

The previous post gives you the solution; whitelisting the utility in your antivirus programme is the fix.

Edited January 26, 2023 by Aishagain

[VenKellie]

happening to me too, FS suddenly taking awhile to load up ever since i switched caching from my SSD to my HDD. I figure its just my hard drive being slow.

[Aishagain]

These various slownesses and glitchiness are phenomena we have probably all encountered over our time in SL.  I've been here since 2008 so I have seen a lot of weird goings on, most of which I can put down to operating system or PC glitches.

The last Firestorm (6.6.5) was very slow to load and I never found out why...it always did so I didn't worry.  The present one (6.6.8) is much quicker for me but loads of folk have a variety of issues, some of which are related to the C++ redidtributables that most folk have lurking in their software (not everyone though) or other maladies that suggest their antivirus programmes are being more aggressive than they used to be.

If weird things did not happen, it wouldn't be SL, would it?

[Henri Beauchamp]

This is likely due to the new asset disk cache code: Windows is especially slow at scanning its files just after a reboot, on first launch of the viewer. This can lead to a ”pause” in the viewer startup procedure that can last for 3 minutes or more (depending on the size of the cache and the speed of your disk). This also explains why wiping the cache (in AppData) temporarily fixes the issue.

I added a specific (Windoze-only, since Linux and macOS do not have such an issue) work-around for it, so that the Cool VL Viewer only scans this cache in a thread, avoiding any minutes-long freeze.

Firestorm and other viewers are calling LLDiskCache::dirFileSize() on startup, which itself scans the whole disk cache to compute the usage in MB; this should not be done in the main thread, under Windows... TPV devels are welcome to ”borrow” my code instead.

Note that I already reported this issue at the Open Source meeting, when the new cache code got implemented... Yeah, one more ”I told you so !” (I lost the count of them).

Edited January 26, 2023 by Henri Beauchamp

[Flea Yatsenko]

I've been having problems with the official viewer as well. In a VM or under WINE it will run once, then after you start it again it fails any start up checks (either invalid graphics or invalid bit depth on the new materials viewer). It's excessively obnoxious because it works fine in WINE until you restart, then it just fails the start up test. And --noprobe and --ignorepixeldepth  do not work either. I just want to upload some mesh and get to work and I have to download all sorts of different viewers only to find random things are broken (latest Firestorm doesn't keep linked object names from Blender anymore, which I need). Same thing happening in my Windows 10 virtual machine.

Forgive my little rant but this is completely ridiculous I have to go through so many hoops just to do basic tasks in SL.

[Henri Beauchamp]

5 hours ago, Flea Yatsenko said:

I've been having problems with the official viewer as well. In a VM or under WINE it will run once

The viewer got serious issues when ran under Wine (due to Wine bugs). The Cool VL Viewer got guards (it will refuse to run under Wine before v7.20, because it uses a new boost version which directory iterator code hits a Wine bug), and workarounds (e.g. for a file write pointer bug, affecting all Wine versions).

As for VMs, it will be even worst, due to their poor/incomplete/bogus OpenGL support (most of the time, you will end up running it with llvm-pipe, i.e. a slooow CPU emulation of OpenGL).

However, I fail to see why you try and use a viewer such as Firestorm (or TPVs such as Cool VL Viewer, Alchemy and a few others/older) via Wine, when it got a Linux build that works beautifully (well, the current version crashes inside APR after exit, but this will go unnoticed by most people not looking in the system logs)... It should also be noted that Firestorm (and other Linux TPVs) are unaffected under Linux by the slow start bug reported by the OP here. 😜

Edited January 30, 2023 by Henri Beauchamp

[Gavin Hird]

See if you have an entry of 

<key>RenderGLCoreProfile</key>

in

AppData\Roaming\<the name of the viewer>\user_settings\settings.xml. (for Windows)

~/Library/Application Support/<viewer name>/user_settings/settings.xml (for macOS)

If you do, delete it and see if it will start.

Edited January 30, 2023 by Gavin Hird

[Aishagain]

2 hours ago, Gavin Hird said:

See if you have an entry of 

<key>RenderGLCoreProfile</key>

 

<key>RenderGLContextCoreProfile</key>

is what I see, I assume you meant that, Gavin?

(I should add that I do not have this hang-up issue)

Edited January 31, 2023 by Aishagain

[Gavin Hird]

5 hours ago, Aishagain said:

 

<key>RenderGLContextCoreProfile</key>

is what I see, I assume you meant that, Gavin?

(I should add that I do not have this hang-up issue)

No that key shall be there, but if the one I mentioned is present it never manages to start the graphics system.

[Aishagain]

2 hours ago, Gavin Hird said:

No that key shall be there, but if the one I mentioned is present it never manages to start the graphics system.

Ah, understood.  I hadn't strayed into this forest before!!

[Gavin Hird]

11 minutes ago, Aishagain said:

Ah, understood.  I hadn't strayed into this forest before!!

There was a code change: "SL-16717 Rename RenderGLCoreProfile to prevent compatibility issues", but the code never cleaned it out of the user's settings.xml file, so if it is present the viewer gets stuck in some limbo displaying the "Initializing Texture Cache" message.

[Henri Beauchamp]

1 hour ago, Gavin Hird said:

There was a code change: ”SL-16717 Rename RenderGLCoreProfile to prevent compatibility issues”, but the code never cleaned it out of the user's settings.xml file, so if it is present the viewer gets stuck in some limbo displaying the ”Initializing Texture Cache” message.

This won't change a thing !

”RenderGLCoreProfile” is no more present in Firestorm's code (you can check yourself if you do not believe me with a 'grep -r RenderGLCoreProfile *' from inside the Firestorm sources tree).

Old debug settings saved in the user_settings that are not part any more of the reference settings*.xml file(s) (the ones in the app_settings/ sub-directory of the viewer installation directory) of new viewer versions are simply ignored.

Edited January 31, 2023 by Henri Beauchamp

[Gavin Hird]

3 hours ago, Henri Beauchamp said:

This won't change a thing !

”RenderGLCoreProfile” is no more present in Firestorm's code (you can check yourself if you do not believe me with a 'grep -r RenderGLCoreProfile *' from inside the Firestorm sources tree).

Old debug settings saved in the user_settings that are not part any more of the reference settings*.xml file(s) (the ones in the app_settings/ sub-directory of the viewer installation directory) of new viewer versions are simply ignored.

It is not in the current source tree, but is the current source exactly what is in the released version?  

In any case, it might also be worthwhile to check the value of RenderGLContextCoreProfile in the users settings.xml, if it exist, and if it differs from the default setting. 

 

Edited January 31, 2023 by Gavin Hird

[Henri Beauchamp]

54 minutes ago, Gavin Hird said:

It is not in the current source tree, but is the current source exactly what is in the released version?

I meant v6.6.8 sources. If you are not convinced, grep for ”RenderGLCoreProfile” from inside the installation directory...