search

secondlife / jira-archive

2 stars 0 forks source link

[BUG-7931] Avatars not rezzing - cellular network #15587

Closed sl-service-account closed 8 months ago

sl-service-account commented 9 years ago

Steps to Reproduce

I logged in on November 25th, teleported to my favorite beach, and did nothing. It was when I logged in I noticed that things were taking way to long to rezz..

Actual Behavior

For the past two days I have been experiencing slow rezzing items in world.. I log in, teleport from the linden home I have and then off to my favorite beach, once there I have to wait sometimes up to an hour maybe longer for avatars to rezz completely and then when they do they are missing parts. For instance, a stomach may be missing, or an arm, or their feet.. Often times you can see the skins that creators have made and you can see the signatures to them, for instance, someone may have on a bikini, or a suit, well what I see is an underlying layer that is not what eventually rezzes.. I know its not my graphics card as as it has handled everything fine up until a few days ago.. I have even gone so far as to swap my Nvidia Gtx 760 with my old graphics card and it too rezzes items the same way. I have rolled back the drivers for the 760 to some that were released over the previous months and its still not operating properly.. Not only does this do this on the Second Life Viewer, but it has done it on every other viewer I have tried.. Keep in mind I use my cell phone as a hot spot for my computer, and have never had an issue like this, NEVER!

Expected Behavior

I was expecting everything to rezz just like it normally does, insteaed I was greeted with items in world, not rezzing for over an hour..

Other information

I have attached 9 photos so you can see what I am seeing from my end..

Attachments

Original Jira Fields | Field | Value | | ------------- | ------------- | | Issue | BUG-7931 | | Summary | Avatars not rezzing - cellular network | | Type | Bug | | Priority | Unset | | Status | Closed | | Resolution | Duplicate | | Reporter | Danga Ling (danga.ling) | | Created at | 2014-11-29T21:23:01Z | | Updated at | 2014-12-10T18:08:37Z | ``` { 'Business Unit': ['Platform'], 'Date of First Response': '2014-11-29T17:29:39.859-0600', 'Severity': 'Unset', 'System': 'SL Viewer', 'Target Viewer Version': 'viewer-development', 'What just happened?': 'For the past two days I have been experiencing slow rezzing items in world.. I log in, teleport from the linden home I have and then off to my favorite beach, once there I have to wait sometimes up to an hour maybe longer for avatars to rezz completely and then when they do they are missing parts. For instance, a stomach may be missing, or an arm, or their feet.. Often times you can see the skins that creators have made and you can see the signatures to them, for instance, someone may have on a bikini, or a suit, well what I see is an underlying layer that is not what eventually rezzes.. I know its not my graphics card as as it has handled everything fine up until a few days ago.. I have even gone so far as to swap my Nvidia Gtx 760 with my old graphics card and it too rezzes items the same way. I have rolled back the drivers for the 760 to some that were released over the previous months and its still not operating properly.. Not only does this do this on the Second Life Viewer, but it has done it on every other viewer I have tried.. Keep in mind I use my cell phone as a hot spot for my computer, and have never had an issue like this, NEVER! ', 'What were you doing when it happened?': 'I logged in on November 25th, teleported to my favorite beach, and did nothing. It was when I logged in I noticed that things were taking way to long to rezz.. ', 'What were you expecting to happen instead?': 'I was expecting everything to rezz just like it normally does, insteaed I was greeted with items in world, not rezzing for over an hour.. ', 'Where': 'http://maps.secondlife.com/secondlife/Sexy%20Nude%20Beach/180/162/21', } ```
sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-11-29T23:29:40Z

Note: Danga is already using the HTTP-RC viewer http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release/3.7.21.296736

Heya Danga,

There have been a number of people having this problem since CDN was rolled out to the main grid. A number of those affected are connecting to SL over a cellular network but it is also happening to people who are using a standard connection.

See BUG-7851 for the main CDN cellular network issue. See BUG-7739 and BUG-7688 for examples of the same symptoms on a standard connection.

All those having this problem report the same symptoms - corrupted/wrong textures showing on avatars and lots of missing mesh.

Thanks!

sl-service-account commented 9 years ago

Danga Ling commented at 2014-11-30T00:03:56Z, updated at 2014-11-30T00:21:38Z

Typically when Logged in I stay logged in for hours on end, and though I do not always interact while logged in, I keep the viewer up on a second monitor off to the side.. The Device I am using is a Samsung Galaxy Note 3 on Verizon Wireless 4GLTE network Running Android 4.4.4. Baseband Version N900VVRUDNJ6. My current Location is Columbus Ohio. As far as the other viewers I have tried, They are Frirestorm, Singularity, and Black Dragon...

As soon as I am able to reproduce these issues, I will most certainly attach the log files..

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Steve>tracert asset-cdn.agni.lindenlab.com

Tracing route to cds.y8a2h6u5.hwcdn.net [205.185.216.10] over a maximum of 30 hops:

1 5 ms 10 ms 5 ms 192.168.43.1 2 1073 ms 2084 ms 1155 ms 193.sub-66-174-61.myvzw.com [66.174.61.193] 3 702 ms 348 ms 120 ms 225.sub-69-83-75.myvzw.com [69.83.75.225] 4 57 ms 57 ms 23 ms 194.sub-69-83-68.myvzw.com [69.83.68.194] 5 38 ms 48 ms 29 ms 208.sub-69-83-64.myvzw.com [69.83.64.208] 6 37 ms 57 ms 55 ms 1.sub-69-83-66.myvzw.com [69.83.66.1] 7 31 ms 72 ms 43 ms xe-10-1-0.bar2.Cincinnati1.Level3.net [4.59.42.1 3] 8 51 ms 34 ms 42 ms ae-2-3602.edge3.Chicago3.Level3.net [4.69.203.23 4] 9 37 ms 56 ms 47 ms ae10.chi11.ip4.gtt.net [199.229.229.133] 10 38 ms 62 ms 63 ms highwinds-gw.ip4.gtt.net [173.241.128.66] 11 45 ms 41 ms 49 ms 209.197.20.10 12 52 ms 49 ms 49 ms map2.hwcdn.net [205.185.216.10]

Trace complete.

Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Steve>tracert asset-cdn.agni.lindenlab.com

Tracing route to cds.y8a2h6u5.hwcdn.net [205.185.216.10] over a maximum of 30 hops:

1 5 ms 10 ms 5 ms 192.168.43.1 2 1073 ms 2084 ms 1155 ms 193.sub-66-174-61.myvzw.com [66.174.61.193] 3 702 ms 348 ms 120 ms 225.sub-69-83-75.myvzw.com [69.83.75.225] 4 57 ms 57 ms 23 ms 194.sub-69-83-68.myvzw.com [69.83.68.194] 5 38 ms 48 ms 29 ms 208.sub-69-83-64.myvzw.com [69.83.64.208] 6 37 ms 57 ms 55 ms 1.sub-69-83-66.myvzw.com [69.83.66.1] 7 31 ms 72 ms 43 ms xe-10-1-0.bar2.Cincinnati1.Level3.net [4.59.42.1 3] 8 51 ms 34 ms 42 ms ae-2-3602.edge3.Chicago3.Level3.net [4.69.203.23 4] 9 37 ms 56 ms 47 ms ae10.chi11.ip4.gtt.net [199.229.229.133] 10 38 ms 62 ms 63 ms highwinds-gw.ip4.gtt.net [173.241.128.66] 11 45 ms 41 ms 49 ms 209.197.20.10 12 52 ms 49 ms 49 ms map2.hwcdn.net [205.185.216.10]

Trace complete.

I was able to locate the SecondLifeCrashREport.Log, but there is no Stack_trace.log showing in the log folder...

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-11-30T10:05:31Z

There was one secondlife.old session log in your zip but the session was only 3 minutes long.

The instructions on that wiki page arn't that clear. Can you run a session where you reproduce the problems (at least an hour long if you can) and then logout. Do not relaunch the viewer yet. Go to C:\Users\ [USERNAME] \AppData\Roaming\SecondLife Find the folder named "logs" in the SecondLife folder, right click the logs folder -> Send to -> compressed (zipped) folder. Attach the logs.zip to this issue.

Does the Linden viewer Second Life 3.7.21 (296736) Nov 10 2014 19:23:31 (Second Life Release) reproduce this problem just as badly for you as Firestorm and Singularity viewers? Most people who have this problem and are using a cellular connection seem to have the problem less severely on a pipelining enabled viewer. The Linden viewer you are using has pipelining, Firestorm and Singularity viewers do not yet have the pipelining feature.

Others not on a cellular connection having this problem appear to pretty much back to normal on a non-pipelining viewer or if they disable HttpPipelining on the Linden viewer. If the problem is just as bad for you on Firestorm and Singularity, the disabling HttpPipelining probably isnt going to help you, but its worth a try.

For your logs above, please make sure that HttpPipeling is enabled (TRUE).

Activate the Advanced menu in the top menu bar with CTRL+ALT+D Go to Advanced -> Show debug settings -> HttpPipelining -> Set this to FALSE and then relog. Is the problem better or worse or no different for you with HttpPipelining set to FALSE?

Set HttpPipelining back to TRUE. In debug settings again, set HttpRangeRequestsDisable to TRUE and relog. Is the problem better or worse or no different for you with HttpPipelining TRUE and HttpRangeRequestsDisable TRUE? Set HttpRangeRequestsDisable back to FALSE once you have tested (unless it fixes your problem).

Thanks :)

sl-service-account commented 9 years ago

Danga Ling commented at 2014-11-30T20:09:25Z, updated at 2014-11-30T21:18:14Z

So far the SL viewer seems to be ok..( I haven't Tried the other two viewers as of yet ) However, it still takes a few minutes for everything to rezz, I am currently logged in and waiting another 45 minutes before I do the above mentioned steps.. I will post the log files as soon as I am done. The zip files are now uploaded after an hour and 15 minutes of a constant connection, also I included one more image from the sl viewer to show some mesh Items are still not rezzing properly.

Ok so with HttpPipelining set to false, it didn't seem to change much from when it was set to True. I changed it back to True and then set HttpRangeRequestsDisable to True and it seems to have loaded a little faster, however with the textures loading a little faster, I am still noticing some mesh objects not loading within a 5 minute time frame..

sl-service-account commented 9 years ago

Danga Ling commented at 2014-12-02T01:16:15Z

Yesterday evening around 18:00 eastern time everything had started to render fine, there was a bit of choppiness as I would pan around, but tonight? Its right back to the corrupt textures and mesh not loading.. any word on whats going on?

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-12-02T02:36:07Z

Danga, seeing as you can reproduce this problem again, please can you attach your logs to this issue. You deleted the old attachments that actually had a secondlife.log file in there. The new logs you attached on the 30th are just the crashreport.log which only logs any crash reports you sent in, not what is actually happening during a session.

After you have logged out from a session where you reproduced the corrupted textures, before you relaunch the viewer, go to C:\Users\ [USERNAME] \AppData\Roaming\SecondLife Find the folder named "logs" in the SecondLife folder, right click the logs folder -> Send to -> compressed (zipped) folder. Make sure you zip up the whole logs folder, not just a single file from inside the logs folder. Attach the logs.zip to this issue.

Thanks!

sl-service-account commented 9 years ago

Danga Ling commented at 2014-12-02T03:04:06Z, updated at 2014-12-02T03:51:09Z

All Log files have been attached!

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-12-02T04:29:47Z

Perfect!

The secondlife.log file shows the 2 warnings that others having the same problems as you are getting: "Invalid Content-Range header encountered" and "Invalid HTTP response code (0) received from server"

2014-12-02T02:51:01Z WARNING: LLTextureFetchWorker::onCompleted: CURL GET FAILED, status: Core_4 reason: Invalid Content-Range header encountered
2014-12-02T02:51:01Z INFO: LLTextureFetchWorker::doWork: HTTP GET failed for: http://asset-cdn.agni.lindenlab.com/?texture_id=03cb872d-5e9c-6c02-4154-d899663364cc Status: Core_4 Reason: 'Invalid Content-Range header encountered'
2014-12-02T02:51:01Z WARNING: LLTextureFetchWorker::doWork: 03cb872d-5e9c-6c02-4154-d899663364cc mLoadedDiscard is -1, should be >=0
2014-12-02T02:51:01Z WARNING: LLTextureFetchWorker::doWork: Decode entered with invalid mLoadedDiscard. ID = 03cb872d-5e9c-6c02-4154-d899663364cc
2014-12-02T02:55:44Z WARNING: LLCore::HttpLibcurl::completeRequest: Invalid HTTP response code (0) received from server.

Also some other suspicious looking Easy_28 and Easy_56 warnings...

2014-12-02T03:00:53Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 1DD17820 failed after 8 retries.  Reason:  Timeout was reached (Easy_28)
2014-12-02T03:01:24Z WARNING: LLCore::HttpPolicy::stageAfterCompletion: HTTP request 5066D340 failed after 8 retries.  Reason:  Failure when receiving data from the peer (Easy_56)

KDU is also grumbling a lot:

2014-12-02T03:31:05Z INFO: LLKDUMessageError::put_text: KDU Error: Illegal inclusion tag tree encountered while decoding a packet header.  This problem can arise if empty packets are used (i.e., packets whose first header bit is 0) and the value coded by the inclusion tag tree in a subsequent packet is not exactly equal to the index of the quality layer in which each code-block makes its first contribution.  Such an error may arise from a mis-interpretation of the standard.  The problem may also occur as a result of a corrupted code-stream.  Try re-opening the image with the resilient mode enabled.
2014-12-02T03:31:05Z INFO: LLKDUMessageError::put_text: KDU Error: Kakadu Core Error:

Did you have HttpRangeRequestsDisable set to TRUE or FALSE that session?

sl-service-account commented 9 years ago

Danga Ling commented at 2014-12-02T04:33:42Z

It was set to false..

sl-service-account commented 9 years ago

Whirly Fizzle commented at 2014-12-02T07:31:13Z

Wireshark from Danga (QAModeHttpTrace 2): https://drive.google.com/a/phoenixviewer.com/file/d/0B37KRBZuDSmIOFJSM29CR01TSDA/view?usp=sharing Danga system/network info/settings: https://docs.google.com/a/phoenixviewer.com/document/d/10zCyDYdpC9kK4wkLo-Q-aPsI898vCpqICym6g8XXJRM/edit?usp=sharing (Above shared with Monty & April)

sl-service-account commented 9 years ago

Kyle Linden commented at 2014-12-10T18:06:41Z

Hi Danga,

Thanks for the report, I will make sure your wiresharks are referenced in the main Jira tracking this issue.