Seems like the viewer is taking longer to start recently. Test that

[Dan-Linden]

Environment

26.2.0.24254827122
Windows11

Description

The viewer seems to be taking longer at the "Clearing the cache" stage before the SL window appears.

Reproduction steps

1. Unfortunately, I do not have reproducible steps. Some sessions seem take about a minute before the Login screen appears while others take a few seconds.
2. Start the viewer and see how long it takes for the viewer window to appear.
3. Compare with older viewers.

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #5655 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @Dan-Linden (replace 20 with the amount, and @Dan-Linden with the user to tip).

📖 If you want to learn more, check out our documentation.

[jellyfish-linden]

Second Life Release 26.2.0.24254827122 (64bit) - Windows
This took a while. Like a few minutes.
SecondLife - Copy.log

[fmartian]

Noticed that too, already back a few months. Assumed it had something to do with my own builds and it was rather inconsistent. Sometimes it was fairly fast other times it took up to a minute or more. My investigations however didn't point at anything specific though.

[Hecklezz]

As for the viewer sometimes taking a few minutes to start, one of the reasons for this is the result of the purgeCefStaleCaches function call that now exists in LLAppViewer::initCache since the CEF upgrade.

We have had dozens of reports of this since our Firestorms 7.2.3 release, and 1 solution that worked for everyone that tried, was whitelisting the viewer AND the cache folder. Every user who successfully did this no longer had this issue any more and the viewer no longer got stuck for multiple minutes on some startups. So it seems antiviruses (most had used Windows Defender) seem to really hinder the filesystem access of the new CEF cache folders we now have and deleting them (likely because it is tens of thousands or even hundreds of thousands, of small files).

A solution I implemented in Firestorm which also worked (for those who aren't whitelisted and/or refuse to do so for "security reasons"), was to have the CEF cache purged in a background thread.
Here is the commit where I implemented this in some form. It is a bit crude but works, and I'm sure there is a more elegant way of doing this- FirestormViewer/phoenix-firestorm@4cbca3e

[akleshchev]

Thank you for the info! A thread is probably overkill, it's a one-tme task, so we can drop it onto a worker thread (assuming they are initialized).

[Dzonatas]

long start... I noticed it a few years ago. It seemed like the initialization stage is being played for volatile or tainted textures that then appear as a ton of small files. A slab of it, under Linux, is not a bad idea. Windows 11 can emulate it within the slab, too. It depends on the stack mode or ROI, however. Redoing the inventory for more than 10,000+ objects also... just needs the right thread for its modal.

[Dan-Linden]

Passed QA.
Verified on Second Life Release 26.2.0.25021396775 on Win11/OSX in the scope of https://github.com/secondlife/iqa/issues/643

I don't know what the exact repro for the bug was, but I've been using this viewer a few days and haven't seen this bug appear.

If it does re-appear in this viewer or later, please leave a comment and the SecondLife.log.