"Use HTTP for receiving textures" - how to disable in new FS?

[LiamZander]

Hey there! 

 

Since new Firestorm update I wasn't able to disable this option, it's just greyed out. It has always been causing a massive performance drop and I would rather wait for textures to load in over time rather than using this option, because freezes and massive lag spikes made going around sl quite frustrating for me.

Has something changed in the way textures load or is there any way around to be able to disable it? It's quite a thing for me so I will appreciate any kind of help. 

 



[Phoebe Avro]

You have to use it now since server side baking requires it.

[Theresa Tennyson]

The way HTTP connections are  made has been changed. Go to "Advanced" - "Debug" and check the "HTTPPipelining" setting. It may help to change it from "TRUE" to "FALSE" or vice versa.

[Prokofy Neva]

This was a great tip because I suspected HTTP textures was the culprit for a new problem I developed: not being able to rez anything out of inventory for long periods of time. Each new item selected would require a long wait for my 53,000-item inventory to load, then settle and then enable me to pull out the one selected -- but only after erasing the search term.

Then I would have to do this again and again for each new item rezzed -- a huge chore. The workaround of "wear" and "drop" doesn't work for "mesh" although "add" sometimes does -- but then you have to bat away error messages. All in all, a huge drag.

This has been an annoyance I've had for years -- not being able to pull inventory items out after searching for them unless I erase the search term. Does everybody have it? I think it's some sort of pipeline problem.

Mind you, I've done everything else to reduce lag like lower draw distance, etc. and I routinely would uncheck http textures in the old version of it because unless I did I would crash.

Also ridiculously long waits for terraform actions to "take" -- I have to highlight and hold two parcels I want to link for more than a minute to make it "take" -- routinely when I click on the arrow to look at the prim owners on parcel, I get "nothing" or I have to wait forever. This has made work unbearable.

I don't know why after all these years it has to be. An inventory of 50,000 shouldn't be the daunting search project it seems to be. A land group of 650 people shouldn't be the lag monster it is. And so on. These are trivial, and supposedly they have Google Search Appliance working for them. Why is this?

 

 

[LiamZander]

I changed the value, I will try and use it now for a while to see if its any better. It's quite a shame for me, because things used to work pretty well and then they made some different choices and....it is what it is. 

 

Thanks. 

[Nalates Urriah]

There is a reason that the Lab is going to HTTP protocol for more and more parts of the server-viewer connection, it works way better. If you are having problems, something is wrong in your system or connection.

The SL team is always looking to reduce lag. Using HTTP is one of those ways. They are modernizing the HTTP tech in the viewer and how various parts of the viewer use it. Inventory is currently being worked on. New inventory API's are being put in place. Eventually (2016) the old API's will be removed from the servers. Some, such as texture downloading, already have been. Search mine or Inara Pey's blog for details on where that process is currently and to keep up with it.

As the Lab develops Project Sansar they too are looking at how to do things faster. Between the two groups new ideas are coming up and what can be used in SL gets added, or at least considered.

 

Prokofy, if your inventory is consistently taking a long time to load, (what is a long time?) check your connection to SL and your caching. Having a good Internet connection is not the same as having a good connection to SL. http://blog.nalates.net/2011/10/26/troubleshoot-your-sl-connection/

If you are using a special drive for your cache, check it. If it is a physical drive is it working well? (dskchk from command line or right-click the drive->properties->tools->error checking Check now... Also, drive makers make software for testing a drive to detect impending failure. Visit the manufacturer's site, get the software, and test.

If you use a RAM cache, be sure it is restoring the cache from your HDD on computer start up. Otherwise you are reloading your entire cache from SL at each computer restart.

I have an inventory of almost 50k items. It isn't slow loading. It loads in way less than a minute. Inventory searches are nearly instantaneous. If your inventory is flat (meaning you don't make lots of folders), that is a problem. At viewer start it loads all the folder names first, then all the items items in each folder. So, it is an all folders read first. That request on a good connection even then will time out at upwards of 200,000 folders (that limit was recently - this year - tested). Depending on the quality of the connection, a request for a folder's contents can time out when more than 5,000 items are in a single folder. In some cases this can even prevent a user logging in. In that case one has to contact support and they run a repair tool that re-organizes inventory creating folders and placing no more than 5k items per folder.

That you have had to disable HTTP in the past or crash suggests a problem on your side. Try two viewers and the SL Viewer should be one of them as a troubleshooting step. It provides a known reference. Are both behaving the same way?

If you have more than one drive, place the viewer cache on the second drive (other than the one the viewer is installed on). Does that help or hurt?

That you overall seem to have serious lag and have had through a number of viewer versions (problem persisted for years) suggests an issue with your computer, setup, or connection.

[Prokofy Neva]

Nalates, I appreciate your detailed answer but there's a larger issue at stake: it's long overdue for Linden Lab and power users like you with inside connections to the platform to stop blaming the user and playing PICNIC.

I have fiber optic cable and a good connection and not any of the routers mentioned in your link; I upload and download YouTubes and access all kinds of content that can take time and lag your computer -- but it doesn't. Only Second Life does this. My son plays all kinds of games and edits films and downloads movies and there isn't this latency. Only with Second Life.

Second Life shouldn't have to have to require people to have a PhD in physics or computer science to access their streaming virtual world. They need to focus more on the user experience of simply logging on and seeing the world -- let alone all the other distractions they get entranced with like avatar feet shadows or materials-ready viewing and focus on this basic function.

Now in my 12th year of SL, I've had every kind of computer, hook-up, phone company, graphics card imagineable. And SL has never played optimally and has always been a problem for me. It's a marvel how I've stuck with it even when seeing mere mud for long stretches of time. 

Sure, HTTP is a way to reduce lag ,but if it crashes you and it's "on my end" and it happens for so many people -- and it does because I discuss this with all my customers -- then they need to accommodate customers and call up Verizon or call up Nvidia or whatever their problem hardware companies are and THEY need to do that adjusting and negotiating, not making the user do this. It's their platform. If they want customers, they need to do this.

Everything is fine on chkdsk, Nalates, that's not the issue. And BTW your instructions for doing that won't work on every machine. "Works on My Machines" is an insidious problem in the SL community. I've never heard of typing "dskchk" ever, on any machine, even back in the days of very primitive computers in the 1980s. You type "chkdsk". You can't get to administrative level by just getting the command prompt. So on Windows 8 you need to press the windows button plus "X" together to get the "power menu" and then select "use as administrator" then run the chkdsk.

And so on. I've done these things -- they're not the issue.

Nobody has all the drives you describe or does all these geeky things you describe in normal SL usage. And that's what the Lindens and their inside pals need to accept and stop serving as an obstacle to customer usage. This needs to be streamlined and treated not as a problem of user ignorance or "lack of a set-up" or "lack of a connection" (good Lord, we all connect to the Internet!) but *lack of Linden Lab's ability to streamline their product so it can be used normally and they can have more users and better retention."

When the automobile first appeared, there were these special people -- car mechanics who had five minutes before been rude stable boys -- who appeared to run these mysterious machines. They cranked them up and oiled them and drove them and everyone marvelled as they wrapped themselves in blankets and got covered in soot. 

But in time this institution of rude stable boys-turned mechanic/drivers (read: coders and programmers) receded, and the manufacturers made the cars more usable by the ordinary person. Sure, they would still have to occasionally go to garage mechanics and pay an arm and a leg for routine maintenance, but many things, even oil changes, they could do themselves.

So it is with computers, Nalates, and the Internet. All this hobble gobble you are insisting everyone absorb and jump through will go the way of the in-house mechanic and jump seat and the car blankets of 100 years ago.

[Xilin Yifu]

Hear hear Prokofy!