🪰 Viewer Bug Reports

System Details: RTX 5080 CPU 9950x3d RAM 64GB DDR5 6000mhz Issue: When logged into the viewer, after a seemingly random time the application just force closes, there are no Viewer Logs BUT Windows Event Viewer logs; Faulting application name: SecondLifeViewer.exe, version: 26.2.0.48334, time stamp: 0x69fa16a3 Faulting module name: nvoglv64.dll, version: 32.0.16.1074, time stamp: 0x6a469d4b Exception code: 0xc0000409 Fault offset: 0x00000000010cba3d Faulting process id: 0x59CC Faulting application start time: 0x1DD0F127FE6A01A Faulting application path: C:\Users\x\AppData\Local\SecondLifeViewer\current\SecondLifeViewer.exe Faulting module path: C:\WINDOWS\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_b26cc1edfbb8f4d0\nvoglv64.dll Report Id: 11c2dfe4-8828-494e-a930-458ff0b7f4e2 Faulting package full name: Faulting package-relative application ID: There is a directly related OpenGL driver crash that always comes at the same time: The description for Event ID 1 from source NVIDIA OpenGL Driver cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. If the event originated on another computer, the display information had to be saved with the event. The following information was included with the event: Unable to recover from a kernel exception. The application must close. Error code: 3 (subcode 7) (pid=22988 tid=22492 secondlifeviewer.exe 64bit) Visit http://www.nvidia.com/page/support.html for more information. The system cannot find the file specified ________________________ I have done some extensive testing on my Machine to rule out any System instability or other hardware issues, I have run a full memory test on the GPU and the system + CPU. No errors were found with my system. A full reinstall of Windows was done, and various versions were tested. Studio driver, rolling back to version 580.x. I have tried several driver versions rolling back to even 580.x to no avail. There must be something in the way the most recent NVIDIA cards use the OpenGL driver in a way the secondlife Viewer does not like. Now the reason that strongly suggests that this is a Driver issue with the newer Nvidia cards kis this; I tested another Install from the same windows11 ISO on a PC system with the following specs: RTX 3080 TI CPU I9-12900K RAM 32GB DDR4 3600mhz Both have the most recent NVIDIA game ready driver installed which are 610.x The Viewer however does not crash on the system with the 3080TI, this suggests that something must bite itself with the driver of the more recent cards.

I spent days trying to find the bug in my flight physics code that was causing this, only to discover that it was the viewer camera all along. The problem is that sometimes the aircraft flies "visually" smoothly at any speed up to 100 meters/sec; and other times it's visibly jerky, appearing to "vibrate" (change in apparent size many times/sec) as though the camera was acting like a spring instead of being fixed in place behind the vehicle. I'm using the eye/offset calls: llSetCameraEyeOffset(eye); llSetCameraAtOffset(offset); This is because the "newer" (21 years old instead of 23) follow cam is missing features that would be necessary to produce the same behavior, and I find it unsatisfying and confusing to use for aircraft. I instrumented my vehicle with code that captures llGetVel() and llGetOmega() 20 times/sec (rotated into the local reference frame), then uses llSetText() to display mean, standard deviation, and range once per second. What I discovered: Sigma (standard deviation) for local X can be very low (0.0 to 0.02) in level, unaccelerated flight regardless of whether the visual apperance is jerky or not. There is no difference. When it's visually smooth, sigma can actually be quite a lot higher, closer to 1, and it still looks totally smooth. This happens during accelerating and turning. Local Y's sigma is typically very close to 0 in either case. Local Z's sigma is typically very close to 0 in either case. All three axes of llGetOmega() are always zero unless the aircraft is turning, climbing, descending, or yawing. If the statistical analysis is not enough of a smoking gun, here's another: When the aircraft is flying smooth, and I refocus the camera on my avatar, it starts getting jerky, like the camera is damping at some wild speed. Single-frame jumps of tens to hundreds of pixels along the axis of motion. The attached screenshot is the llSetText() stats output when the camera was jerky. Zero standard deviation in this regime + jerky visuals, vs. standard deviation WAY higher during maneuvers when the camera is smooth, provides strong evidence that this is a viewer bug. My code is invariant either way. My stats are invariant either way. When flying smoothly, refocusing the camera makes it do the jerky rendering thing. And sometimes it does the jerky rendering thing whether I do that or not.

I have tipjars that combine a non pbr material link and a pbr material link. Sometimes some of them will randomly show the pbr part as a blank material (no texture, no material parameters). In the included captures you can see the 3 hearts on the left are fully blank, and on the right the 1 on the top is rendered normally while the 2 others see their pbr part being blank. (the rainbow part is non pbr). This happens more or less depending on the days .. and one viewer can see them alright while an other viewer will see some of them rendered with a blank material. This issue has been present for months, so it's not just the latest updates. Also it happens on PC or Mac.

Some streams, like for example "green.streamhood" do not play anymore in the latest version of the viewer. When a DJ sets it, only people running Firestorm hear it, I don't hear it anymore, used to hear with previous version.

I have a ton of details, screenshots and debug logs on ticket 2411959 (happy to share whatever is needed), but in brief - any shape, any creator, even just starting from scratch - 4 out of 5 times, when I edit and save, the resulting shape "cannot be found in inventory". This has been happening consistently for months. It is occurring in both Windows and Linux environments, and I have tried in both Firestorm (my default viewer) and the Second Life viewer. This isn't on a small scale - I edit nearly every single shape, and often about 3 different ways - so it's a debilitating issue, particularly as my "workable" process has been to delete the shape, then empty trash, clear inventory cache and then relog - and then it's a minimum of half an hour before I can do ANYTHING while it rebuilds my inventory - having this happen is a challenge since I can end up having to do this over and over when the subsequent shape edits corrupt as well - I've had it happen 8 times in one day. I'd be really grateful for any help - I opened a ticket months ago, but unfortunately no solution was found, and it was suggested I try here to see if I can find a solution. I've tried disabling both VPN and antivirus (no effect) rebooting modem tried both wifi and direct connections tried both Windows and Linus tried both the SL viewer and Firestorm

The issue appears to be linked to the quantity of subfolders with the precise number being unknown. To reproduce: Create a folder structure like so: My Inventory -> Clothes --> Boots --> Tops --> Jewelry --> Pants --> ... Each subfolder will have a varying complexity of items in them, such as additional subfolders or either attachments or BOM. Detaching the "Clothes" folder will remove every possible entry from the "Wearing" tab, most notably also items from outside the "Clothes" folder. Expected behaviour would be that it only removes items from said folder, not unrelated ones. A possible workaround is to multi-select all subfolders and detach them that way. This results in the expected behavior. See attached screenshots for a demonstration of the issue. Step 1: Select top folder and Take off folder items Step 2: Notice the wearing tab clearing out almost entirely with the inventory not updating. Step 3: Detaching any one item from the worn inventory tab will result in the view shown here. Note how even unrelated folders have been detached such as my Main Body folder.