![]() The viewer got serious issues when ran under Wine (due to Wine bugs). I've been having problems with the official viewer as well. ![]() Yeah, one more ”I told you so !” (I lost the count of them). Note that I already reported this issue at the Open Source meeting, when the new cache code got implemented. TPV devels are welcome to ”borrow” my code instead. 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.įirestorm 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. This also explains why wiping the cache (in AppData) temporarily fixes the issue. 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 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. Thing is, most people rarely ever cold-boot every day: they prefer ”sleeping” their 'puter. 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īeq 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 If you got a SSD you are fine, but on a DD. It's just Windows file system being brain dead. Henri Beauchamp: The non-VFS cache works great for me. :-Pīeq Janus: I don't see that dely and I've not seen a Jira Henri Beauchamp: No JIRA initiated by me. and since the latter is using the new asset cache, I won't be surprise it got the same issue.īeq Janus: I think you've dropped plans to rollout the non-VFS cache or at least put them on hold Henri Beauchamp: I saw some people complaining about the slow start of the lastest Firestorm under WIndows after a reboot too. Is there a JIRA? Could be we're fighting with windows for file system accessīeq Janus: also depends on what cache system Vir Linden: Don't know about that one Henri. I worked around the issue by threading the asset cache scanning. Windows is so lame that it takes about 2-3 minutes to scan a 400Mb asset cache where Linux only needs 2-3 seconds !. 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. ![]() Current cache size: ” << sCurrentSizeBytesĮxcerpt from a months old public Open Source meeting (held, monthly, now), where I reported this issue: Cache directory: ” << sCacheDir << llendl Llinfos << ”Nominal cache size: ” << sNominalSizeBytes LLDiskCache::threadedPurge() will instead set sCurrentSizeBytes takes at most a few seconds to get scanned under Linux) ! the cache can take a couple dozens seconds, when the same cache problem with ”SuperFetch”, but even after disabling it, scanning minutes-long delays for large caches on hard disks (obviously a after boot, from the first viewer instance): it causes Windows when the cache directory has not already been scanned Do not call cacheDirSize() on startup from the main thread under Same thing.Ĭool VL Viewer sources: linden/indra/llfilesystem/lldiskcache.cpp file, read the comment for my code's Windoze exception: ![]() 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. Until I restart it for anti-virus updates today like I do basically every week. I have a great computer, optimal for gaming, and it was working perfectly.
0 Comments
Leave a Reply. |