Nalates Urriah

Lindal and Whirly are right. But, I'll say it another way hoping it helps and give you a key troubleshooting tip. A large inventory will not crash you or affect your teleports. However, a large flat inventory, basically everything in one folder, can cause problems. Awhile back something changed and large flat inventories started blocking login. The engineers built a tool for support to rearrange a person's inventory so they could login. Basically, placing things in lots of folders. The pain point on a good connection was about 5,000 items per folder. Less on weaker connections. That you survived with 300k items suggests you do not have a flat inventory. So, deleting 270k items out of inventory was a waste of time... at least in light of the goal of stopping crashes. As you are learning, before you start fixing things identify the problem. Otherwise you do a bunch of time consuming tedious things that do not fix the problem. If Whirly nailed the problem as a 32-bit viewer issue, a change to a 64-bit would have eliminated the problem without deleting inventory. A simple step in troubleshooting is to look in the viewer's log to see what went wrong. Look at the log immediately after you crash or exit the viewer. Logs are replaced the next time a viewer starts. You’ll find the logs in: Windows: C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\ You will change folder and file names based on viewer used... But, they are all similar. crashreport.log – This log is generated when the viewer crashes, the previous version of the file is overwritten. Rename this file if you plan to restart the viewer before examining the file. Otherwise, just read it with a text viewer (Notepad is good). debug_info.log – This file is internally formatted as an XML file. I never find it of much use. It is mostly the specs of your machine. SecondLife.log – This is the main log file. I find it the most useful. Start from the end of the file and work toward the beginning. Search for ‘WARNING’ and ‘ERROR’. With any luck, the messages there will give you an idea of the problem. Recent changes have added a section heading to parts of the file that can identify the general nature of the problem. There are lots of performance stats included. At the end of a non-crash log there are secession stats; Run Time, Average Packet Size, Dropped Packets, Resent Packets, etc. The file is replaced and recreated for each viewer secession. SecondLife.error_marker – I don’t know what information is inside. I don’t have a copy to examine as I write this. The presence of the file indicates where, when, and what error happened. I think this is a disaster backup file for crash reporting in which information about the crash is retained in the event the crash handlers are destroyed before they can create the other more complete crash files. SecondLife.start_marker – There is no information inside. The presence of the file indicates how far into the start process the viewer has gotten. Whether the file exists or not is the pertinent information. SecondLifeCrashReport.log – This is another file internally formatted to XML. It is created when the viewer crashes. I think this is the new version of the crash log. It is mostly text. stats.log – This is a short file containing network statistics. Similar information is in other log files. It is an easy to read set of stats that show how many packets were dropped and resent in a secession. I find the SecondLife.log is the most useful file for tuning and troubleshooting the viewer. It is verbose and reasonably easy to understand. There is a Debug Setting that allows you to increase or decrease the level of reporting. Most of these files are erased when the viewer starts. If you plan to send the files in with a trouble ticket or bug report, place copies in another folder before starting the viewer. Marker files are temporary and may or may not exist at any given time. Entries in the files associated with errors and warnings are labeled as such. That makes them easy to find by searching. Search and read through them starting at the end of the file and working backward. Warning entries are common and do NOT necessarily mean there is a problem. Some warnings are a part of normal operation. Some errors are trivial and do not indicate a ‘noticeable’ problem in the viewer’s operation.

@aliasingishard Your question isn't really clear. Are you making or using an Applier? What is being applied and to what? In general, as a user, there is nothing you can do. An Applier applies whatever it designed to apply to the layer it was designed to apply it to. The target, mesh body, hands, head, whatever is usually designed by someone else. Users usually cannot change either. So, what you see is what you get. There aren't any viewer settings that control any of the aspects involved. Your only option is to talk to the one that made the Applier. A common mistake among the new is to mix the Classic body and mesh attachments. There are mesh attachments made for the Classic body and mesh attachments made for mesh bodies. Using the later on a classic body is possible, but things do not fit well when you try it. The shape sliders aren't much help adjusting fit as the mesh attachment and Classic body respond differently to slider adjustments. thus the two different classes of mesh attachments. I hope this answers your question...

The SL Viewers have been making more use of multiple-threads. Monty Linden recently commented about that here in the forum. I covered it here: http://blog.nalates.net/2017/10/21/cpus-intel-8th-generation-and-second-lifes-viewer/ Still there is a main thread. It needs great single-core performance. So, core speed is more important then the number of cores. So, cykarushb is giving you pertinent advice. It looks like you are CPU bound...

The voice stuff is more complex than the main SL connection. Voice gets handled in the third-party Vivox servers. So, there is a double/duel connection that you are dealing with. Internet connections change by the second as do the connection pathways. So, a good general Internet connection and basic SpeedTest.net results may not be indicative of your connections to Vivox and SL servers. The viewer stats (Ctrl-Shift-1) are a mix of your computer, connection and the SL servers performance, so they are not a clean measure of the connection. They are focused on the SL parts. So, you won't know much about the Viviox connection or you network perfomance. There are issues that Vivox has been working on. Some of the new code is in an RC viewer. So, you may want to try enabling Willing to try RC viewers... in Preferences. Then go to the Alternate Viewers page and get the RC Second Life Voice Viewer version 5.0.10.330039 and install it. If the problem stops, you know it is a viewer thing. You can try some things to improve your system's ability to handle multiple connections. But, consider that a last resort. Info is here: http://blog.nalates.net/2011/10/26/troubleshoot-your-sl-connection/ Most voice altering is done on your workstation. So, lots of memory and free CPU cycles is important. You can use the CPUID HDMonitor (free) to see how your computer is doing. If you can watch the viewer and HDMonitor at the same time you'll be able to see if voice is dropping out when CPU or memory use is high. If that is the case the problem is in your computer. In which case the first steps are to try restarting your computer and running ONLY the viewer. If that helps, the voice morph is pushing something in your computer to the limit and having problems. This would mean the fixes likely to improve things are more memory, faster memory, overclocking the CPU... new faster computer... Before going drastic and buying a new computer, Google for information on how to eliminate background tasks in Windows. The less stuff running in background, the more CPU and memory you'll have for the viewer and voice morphing. Window runs a ton of stuff in background. If you run anti-virus software, white list the SL viewer program folder and cache. This is a very minor risk and usually improves viewer performance by reducing the work the system has to do to virus check stuff the Lindens have already tested.

First, when asking these types of questions give us information about your computer and viewer. Use the viewer's HELP->ABOUT... to gather the info and then paste it in the post with your question. Right-click the avatar and try Reset Skeleton and Animations. The other quick try remedy you are doing, relog. I see similar problems when I go cam-shopping, park the avatar and cam all over the region. After a few minutes away from the avatar the viewer drops it from the Interest List. When I come back I'm often a mess of triangles, confused polygons. The usual fix is to remove my mesh body and then add it back, what NoraJulian said. This seems to be a worse problem in Firestorm. But, it isn't exclusive to FS. When you have this type of problem clearing the cache can make it worse. These days a cache clear is a last resort and even then you need to have a strong indication there is a corrupt fine in the cache. Otherwise, it is almost always counterproductive.

Deformations of mesh heads are only caused by animations, poses, scripts, and shape settings. While it is possible for a mesh to error in download and be deformed it is rare. So, the script in the eye would be my first suspect. Firestorm will give you information on the script. Is the script there when you reset to the Test Female? Hopefully not. So, at what point in your avatar rebuild does it appear? You'll have to add ONE item and check. Do NOT wear an AO during this rebuild. Hopefully you'll find what the script is associated with. It may not be the problem. But, you need to eliminate it or reveal it as the problem. The only other source of script-animations is your AO's, RLV relays, and collars, Eliminate most of these causes by using the Linden Viewer or disabling RLV in a Third-Party viewer. That you are OK for a short time after login, suggests a script or animation runs or plays at some point. Do your testing in a pristine environment. So, a Linden owned region that is empty and deserted. Furball, Pooley, and other regions in the area work. RC Test channel sandboxes are good too. Try BlueSteel Sandbox. There are more and more Bento animations. Those for facial expression not made for your head can create problems. There is no magical mystical viewer glitch or server problem to cause this. If there were we would have thousands of people complaining... So, it is just a matter of searching for the script or animation that is causing the problem.

Let us know how it works...

When you ask a technical question include the info from the viewer's HELP->ABOUT... That gives us driver versions. Also, it will tell us if you are running the 32 or 64-bit version of Firestorm. I assume the problem is the fireplace and wall pillars. The color fail is usually a video card driver problem. Search the forum for your video card model. Some times the latest driver is the problem. Sometimes and old driver is the problem. No simple answer. But, it is easy to try a driver update then start moving to older drivers until the problem is corrected.

There are a load of Windlight tutorials on YouTube. Depending on why you need to change the settings, the Firestorm Viewer may be a better choice for working with WIndlight. It has Photo Tools and the Windlight settings are in an easy to use and find place. Great for quick changes needed for a screen capture. There are several tutorials on setting up lighting in SL. If you need 'lights' there is lots of info on setting up lights for ALM. I make a facelight replacement using Projectors, which is what most dramatic lighting in SL uses. It is full Mod-OK so you can see how all the settings are used. There is a video so you can see the effects, which is mostly about attachment points, not what you need. But, you will see what the lights can do in a dramatic way.

I would be calling way more often. Make a pest of yourself. They log all calls and associate them with a trouble ticket. Management reviews the stats on tickets to see how the customer service people are doing. So, frequent calls catch management's eye. Also, follow the advice given earlier and file a complaint: https://lifehacker.com/how-to-file-a-complaint-against-your-isp-and-finally-so-1714876357

I has been some time since I wanted to run viewers in a virtual environment. I think in the Windows Vista era. Once I had the basic Windows running the viewer wasn't a problem. I forget which virtual system I used. I don't know of Windows Hyper-V Guest...

Let me know when you figure out how to do that...

Sounds come from scripted items, parcel sounds, and avatars. That's it. All sounds fall in those groups. Finding them can be hard. The viewer has BEACONS, Menu->World->Show->Beacons or Ctrl-Alt-Shift-N. A panel opens and you can select which items you want a beacon on. There are no beacons for parcel sounds/music/etc. It also helps to turn the draw distance up to 1024. Stuff in the sky can be tricky to find and this helps. Also, cam under the ground with transparent items highlighted, Ctrl-Shift-T . Oops! As Lindal says, CTRL+ALT+T.. Also, some sounds creep in from outside the parcel.

The JIRA says the bug was resolved in February 2017. So, I would think the fix would have made it into the various viewers. Is it still a problem? If so, shouldn't the BUG-41379 report be open? Or reopened?

@Lord Derryth When you check the packet loss it occurred to me to have you check the secondlife.log file. Use the viewer for as long as you think you can without a crash. Close the viewer and look at end of the secondlife.log file in C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\ There will be set of stats at the end of the file. If your connection only drops packets after prolonged use it may be a throttling issue. Whatever, the accumulative stats may show problems we are not seeing in the Ping/TraceRT. You have pretty well established it is NOT your computer or SL by using two computers and two different games and game providers. If your wife's computer works well on another network, that pretty much pins it down. Provide all these details in a long history of your efforts to resolve the issue. Take the mins set a level-1 tech will first read the trouble ticket. Keep it simple and understandable and explain what each result means. Say you have used 2 different computers with the same programs freshly installed. and include what that means: since both have the same problem it is not the Windows or game installs that are the problem. Explain each step this way so as little doubt as possible is left in the Level-1 person and they decide to pass it up the line. There is more in the links below, but in the ticket include the statement that your next step will be to file complaints with the local (city), country, and state agencies. It is more impressive if you look up the agency names. You can call your local city and ask who handles complaints about or the licensing of ISP's. Put enough information in the ticket that they know you are seriously pursuing the agency complaint route. Pleasedo not file the ticket and agency complains at the same time. The ISP may surprise you and actually fix it. We haven't asked about your ISP. The name is not important, but whether they are coming to you via copper wire, coaxial cable, fiber, or satellite is important. At your speeds I would assume fiber or cable is the medium. Don't let the "CONTRACT" thing spook you. If they cannot deliver their side of the agreement, you can break the contract. See: http://www.techradar.com/news/internet/slow-or-unreliable-broadband-your-rights-explained-972542 https://lifehacker.com/how-to-file-a-complaint-against-your-isp-and-finally-so-1714876357

This is sort of my 'last resort' boilerplate. When nothing else is helping, this sometimes gets one a clue. And it is handy to know. When all else is failing and those helping have run out of suggestions, look in the viewer’s log files. The viewer has various log files you can read to get an idea of what has gone wrong. Look at the log immediately after you crash or exit the viewer. Logs are replaced the next time a viewer starts. You’ll find the logs in: C:\Users\[Win_login_ID]\AppData\Roaming\SecondLife\logs\ You will change folder and file names based on viewer used... But, they are all similar. crashreport.log – This log is generated when the viewer crashes, the previous version of the file is overwritten. Rename this file if you plan to restart the viewer before examining the file. Otherwise, just read it with a text viewer (Notepad is good). debug_info.log – This file is internally formatted as an XML file. I never find it of much use. It is mostly the specs of your machine. SecondLife.log – This is the main log file. I find it the most useful. Start from the end of the file and work toward the beginning. Search for ‘WARNING’ and ‘ERROR’. With any luck, the messages there will give you an idea of the problem. Recent changes have added a section heading to parts of the file that can identify the general nature of the problem. There are lots of performance stats included. At the end of a non-crash log there are secession stats; Run Time, Average Packet Size, Dropped Packets, Resent Packets, etc. The file is replaced and recreated for each viewer secession. SecondLife.error_marker – I don’t know what information is inside. I don’t have a copy to examine as I write this. The presence of the file indicates where, when, and what error happened. I think this is a disaster backup file for crash reporting in which information about the crash is retained in the event the crash handlers are destroyed before they can create the other more complete crash files. SecondLife.start_marker – There is no information inside. The presence of the file indicates how far into the start process the viewer has gotten. Whether the file exists or not is the pertinent information. SecondLifeCrashReport.log – This is another file internally formatted to XML. It is created when the viewer crashes. I think this is the new version of the crash log. It is mostly text. stats.log – This is a short file containing network statistics. Similar information is in other log files. It is an easy to read set of stats that show how many packets were dropped and resent in a secession. I find the SecondLife.log is the most useful file for tuning and troubleshooting the viewer. It is verbose and reasonably easy to understand. There is a Debug Setting that allows you to increase or decrease the level of reporting. Most of these files are erased when the viewer starts. If you plan to send the files in with a trouble ticket or bug report, place copies in another folder before starting the viewer. Marker files are temporary and may or may not exist at any given time. Entries in the files associated with errors and warnings are labeled as such. That makes them easy to find by searching. Search and read through them starting at the end of the file and working to the beginning. Warning entries are common and do NOT necessarily mean there is a problem. Some warnings are a part of normal operation. Some errors are trivial and do not indicate a ‘noticeable’ problem in the viewer’s operation. So, one has to do some evaluating.

About the only things I see are the Win 8 and older Nvidia drivers. I am not sure why it shows in 'compatibility mode'. With the hardware you have I would make the upgrade to Win10. I've upgraded a couple of machines from Win7 to Win10 at no cost this month. Use the Windows built-in update. Win8 and Win8.1 are problem versions of Windows. If the Nvidia driver update does not solve the problem, I would assume the problem is in Win8.

I don't see any problem in the TraceRT. The timeouts are common. Assuming you are pinging the LL server the Ping & TraceRT times are almost equal. So, the final ping packet is making it in the same time as the trace route, which indicates the timeouts are not an issue. The only criteria I'm not seeing is packet loss between you and the LL server. I see the Ping 58, but I'm not sure what you were pinging. You may see a more realistic number by reading packet loss from within the viewer, Ctrl-Shift-1. My TraceRT Tracing route to sim10328.agni.lindenlab.com [216.82.50.50] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 9 ms 17 ms 8 ms 10.135.0.1 3 9 ms 9 ms 10 ms 68.6.14.142 4 28 ms 29 ms 28 ms sim10328.agni.lindenlab.com [216.82.50.50] Trace complete. You might try a more arduous PING, use: ping -4 -n 20 sim10328.agni.lindenlab.com You might replace the -4 with -6, its the IPv4 versus v6 format. AFAIK the LL servers only use IPv4. I'm not seeing any packet loss on my pings. But, the max ping time for 20 pings is around 3,000ms the average is 250 to 350. Eliminating the 3 slow pings drops my average to 29ms, which what the standard 4 ping set returns. My viewer typically shows So, the more arduous tests may reveal a problem. You might try borrowing someone's laptop and running a set of tests with a viewer installed on a different machine. The Viewer Stats between the two should eliminate or point to your computer. I would then try the laptop on a different network. Do, you have a friend with a different ISP? Or a work connection that uses a business connection? You should be able to see a difference if it is the network. I have seen COX tell customers that everything was great. From their service center all looked good. But, things did not work right. Until COX was pressed and eventually sent someone out. Then they found a problem. I've seen this once or twice a year with my clients in SoCal. The last run of cable/wire to the home or the gateway has repeatedly been the problem. (I'm not picking on COX. I like them. I've seen this happen with most ISP's.) I don't see where we have asked about your viewer setting Max Bandwidth. It is a depreciated setting only affecting UDP. Yours should be at 1500. It can affect the server and change how fast it pushes data on the UDP protocol. Probably not the issue, but check it off too.

I suggest you ask in the in-world support group for Singularity.

Was the update automatic or did you do a manual update? I ask because there have been some problems with the Linden install program. You might try a manual install to insure you have the right 32 or 64 bit version, provided you are allowing RC installs. If not... go to Alternate Viewers and get a 64-bit version. Try it. Also, make sure your antivirus is not eating your viewer install. You can turn off the AV as you install to test. Also, if you install after a viewer close, you may be installing after a viewer-close crash. This can happen unnoticed. So, to eliminate this possibility, restart the computer and then do the install.

You guys are harsh!

@Syra01 You should be using the Nvidia card. The 940 is old but should work well enough. The Intel HD 5500 is not so good. Laptops will try to use HD Graphics to save power. So, make sure you select performance when you set up your Nvidia settings for SL. I don't see anything wrong with the tech info. The Display settings have been... is just the viewer telling you it's graphics settings have been set to the default for the 940. Once the viewer is running you can go into PREFERENCES and change your graphics settings. The jagged edges on your avatar happens at low resolution and no Anti-Aliasing (AA). AA uses GPU and drops performance. So, it may be off by default on a 940.

Is it normal? No. I'm not a Mac user, so I don't keep up on Mac problems. Did you search this forum for your problem? When asking a tech question use the viewer's HELP->ABOUT... to get the tech info we need and paste it in with your question. Also, are you using just 1 viewer? Many of us use 2. One for daily use and another when we have to troubleshoot problems.

This is good but incomplete. Use the viewer's Help->About... to gather the info we need. You can get after the viewer starts and before you login. This will give us driver versions. Also, is this a desktop or laptop? Do you have anti-virus software? Which? Have you tried disabling it?

You have done all the right things. But, I don't see where you have tested your connection the SL servers. http://blog.nalates.net/2011/10/26/troubleshoot-your-sl-connection/ Your problem description is a classic network issue. Having great speed and a good general Internet connection does not mean you have a good connection to the SL servers. Test that specific connection to see if it is you (looks like you have done a good job of eliminating that), your ISP, the backbone providers, or Linden Lab. Also, try to determine if it is time-of-day sensitive. If your kids or neighbors are streaming movies, your connection could be choking the gateway/router. Older gateways/routers have a limited number of connections. But, if that were an issue it would work better for some time after a restart. Also, you didn't give us your hardware specs. On 32-bit systems and 64-bit ones with less than 8GB of ram you may see these problems too. If this is it the problem gets worse with time logged in.