Release Notes/Second Life Release/3.6.14.285253 - Revision history

Steven Linden at 21:25, 16 January 2014

2014-01-16T21:25:15Z

Steven Linden: Created page with "NOTOC Category:Release Notes ==Release Notes for v3.6.14 (285253) - Second Life Viewer== {{KnownIssuesHeader}} {{GenericDownloadBox|Release|Released on January 16, 2014.|…"

2014-01-16T20:04:08Z

Created page with "__NOTOC__ Category:Release Notes ==Release Notes for v3.6.14 (285253) - Second Life Viewer== {{KnownIssuesHeader}} {{GenericDownloadBox|Release|Released on January 16, 2014.|…"

New page

__NOTOC__
[[Category:Release Notes]]
==Release Notes for v3.6.14 (285253) - Second Life Viewer==
{{KnownIssuesHeader}}
{{GenericDownloadBox|Release|Released on January 16, 2014.|type=release|windows=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i686_Setup.exe|macintosh=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i386.dmg|linux=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i686.tar.bz2|version=3.6.14.285253}}
{{GreenCheckbox|title=Release Notes|body=Overview
==Experimental Fix for Long-Standing DNS Problems==
The mechanism used to perform DNS look ups was changed from an application-hosted DNS resolver to a combination of threads and the host operating system's resolver.
==Mesh Download with Better TCP Connection Behavior==
This release of the viewer reduces by 75% the number of connections used for downloading meshes. It also reuses these connections more effectively further reducing network demands. Those who have experienced connectivity problems from router instability or other networking problems may see a significant improvement.
==General Reliability Improvements in Mesh Upload and Download==
A great deal of work was put into the mesh upload and download code. Better error handling, less frequent request retries, removal of many thread issues and fixes for numerous smaller bugs are a part of this release.

=Details=
==DNS Changes==
The DNS problem usually appears as a login failure with the following alert: Everyone's favorite error

This occurs on all platforms and for multiple reasons, not all of which are completely understood. But they center on a DNS resolver library that issues DNS requests directly from the viewer. To solve these problems, we're trying a scheme that uses threads and the normal operating system resolver library.
If you had this problem and changed your computer's DNS configuration to use Google DNS (https://developers.google.com/speed/public-dns/docs/using) or other DNS service, these changes are particularly relevant to you. We're inviting people who have experienced DNS failures to do some testing of the new scheme.

Revert your DNS configuration.
- Restore your DNS settings to their original values. In most cases, this will mean switching back to the values provided automatically by DHCP. Visiting the Google page may jog your memory.

Confirm that your current Second Life viewer has the DNS problem.
- Before installing the new viewer, login using your old viewer and see if you get the DNS error above.
- If it just works, that's good for you, bad for us: we won't be able to see an improvement. You might leave the DNS settings in their natural form (using DHCP) or go back to Google DNS. Whichever works best for you.
- If it fails to login due to the DNS problem, you've confirmed the original situation still applies and we can move on to the next test.

Test the new viewer; confirm correct behavior.
- Install and login using this release.
- Login and scene loading should work as expected without DNS errors.
- Teleport a few times and verify that scene load continues without DNS problems.

Report test results, good or bad.
- Tell us what you found in http://community.secondlife.com/t5/Second-Life-Viewer/DNS-problems-at-login-a-possible-solution/m-p/2423913

If you experience new problems, please report them in Jira (https://jira.secondlife.com/).

==Mesh Download and TCP==
A few new settings have been added to control the behavior of mesh HTTP operations. We don't recommend changing these settings, they have been set to appropriate values. But special cases may arise and you can try these to work around problems.

Mesh2MaxConcurrentRequests
Controls the maximum number of concurrent mesh download requests issued by the viewer. If you encounter unreliable networks or routers or have a low-bandwidth connection, you might find that lowering this value improves the your experience.

MeshUseGetMesh1
If set to TRUE, the viewer will revert to the original HTTP scheme for downloading meshes. (This also re-enables the old MeshMaxConcurrentRequests setting.) We don't imagine any scenario where this might be needed. But it's available as a possible workaround for unforeseen problems.

MeshUseHttpRetryAfter
Servers are beginning to provide 'Retry-After' response headers for 503 HTTP failures. When this setting is TRUE, the viewer will make use of these headers to better schedule retries of mesh downloads. But there may be circumstances, such as a very high ping-time environment, where it doesn't work as well. By setting this to FALSE, retries will be scheduled according to an exponential backoff rule; the same as is used for texture downloads. If you find that a FALSE setting consistently gives you a better experience, we'd like to hear about your environment. A report in Jira, say.
}}{{GreenCheckbox|title=Resolved Issues|body=* {{jira|BUG-3058}} "DNS could not resolve host name" caused by F-secure - I cant log into Second Life with WIN 7
* {{jira|MAINT-2549}} Viewer mesh loading re-tries are not limited
* {{jira|SH-4184}} Mesh - continue progress on the conversion - less data copy, better thread usage, lower overhead
* {{jira|SH-4306}} IM2 - Complete conversion of mesh downloaders to llcorehttp
* {{jira|SH-4362}} IM3 Mesh uploaders ported to llcorehttp
* {{jira|SH-4364}} IM7 Mesh throughput and cpu usage tuning (partial - sprint 1)
* {{jira|SH-4404}} MM1 Mesh using llcorehttp library - Preparation to release a project viewer
* {{jira|SH-4645}} Viewer hangs on exit after cancelling a mesh upload.
* {{jira|SH-4667}} HTTP: Viewer reports network error instead of a misnamed joint on mesh upload}}
{{RedInfobox|title=Known Issues|body=* {{jira|MAINT-809}} [PUBLIC]Setting 16x antialiasing crashes Viewer in Ubuntu 11.10 with GeForce 6600
* {{jira|MAINT-3200}} WL Haze effects are inconsistent between solid and transparent objects under water.
* {{jira|MAINT-3197}} Rigged alpha attachments don't render for impostors.
* {{jira|MAINT-3198}} Legacy bumpiness renders funny on HUD faces with custom alpha mode
* {{jira|MAINT-3213}} Brightness and Darkness legacy bump maps render incorrectly on Intel GPUs.
* {{jira|MAINT-3135}} Cocoa Viewer: Mac: Maximizing the viewer leaves garbage on the screen
* {{jira|WEB-4659}} Direct Delivery Outbox fails in Linux build
* {{jira|STORM-1971}} MAC viewer - Renaming an object or clothing item in inventory results in automatic wearing
}}

← Older revision		Revision as of 14:25, 16 January 2014
Line 4:		Line 4:
	{{KnownIssuesHeader}}		{{KnownIssuesHeader}}
	{{GenericDownloadBox\|Release\|Released on January 16, 2014.\|type=release\|windows=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i686_Setup.exe\|macintosh=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i386.dmg\|linux=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i686.tar.bz2\|version=3.6.14.285253}}		{{GenericDownloadBox\|Release\|Released on January 16, 2014.\|type=release\|windows=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i686_Setup.exe\|macintosh=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i386.dmg\|linux=http://download.cloud.secondlife.com/Viewer_3/Second_Life_3_6_14_285253_i686.tar.bz2\|version=3.6.14.285253}}
	{{GreenCheckbox\|title=Release Notes\|body=Overview		{{GreenCheckbox\|title=Release Notes\|body==Overview=
	==Experimental Fix for Long-Standing DNS Problems==		==Experimental Fix for Long-Standing DNS Problems==
	The mechanism used to perform DNS look ups was changed from an application-hosted DNS resolver to a combination of threads and the host operating system's resolver.		:The mechanism used to perform DNS look ups was changed from an application-hosted DNS resolver to a combination of threads and the host operating system's resolver.
	==Mesh Download with Better TCP Connection Behavior==		==Mesh Download with Better TCP Connection Behavior==
	This release of the viewer reduces by 75% the number of connections used for downloading meshes. It also reuses these connections more effectively further reducing network demands. Those who have experienced connectivity problems from router instability or other networking problems may see a significant improvement.		:This release of the viewer reduces by 75% the number of connections used for downloading meshes. It also reuses these connections more effectively further reducing network demands. Those who have experienced connectivity problems from router instability or other networking problems may see a significant improvement.
	==General Reliability Improvements in Mesh Upload and Download==		==General Reliability Improvements in Mesh Upload and Download==
	A great deal of work was put into the mesh upload and download code. Better error handling, less frequent request retries, removal of many thread issues and fixes for numerous smaller bugs are a part of this release.		:A great deal of work was put into the mesh upload and download code. Better error handling, less frequent request retries, removal of many thread issues and fixes for numerous smaller bugs are a part of this release.

	=Details=		=Details=
	==DNS Changes==		==DNS Changes==
	The DNS problem usually appears as a login failure with the following alert: Everyone's favorite error		The DNS problem usually appears as a login failure with the following alert:

			<br>

			[[Image:DNSerror.png\|center\|Everyone's favorite error]]

			<br>

	This occurs on all platforms and for multiple reasons, not all of which are completely understood. But they center on a DNS resolver library that issues DNS requests directly from the viewer. To solve these problems, we're trying a scheme that uses threads and the normal operating system resolver library.		This occurs on all platforms and for multiple reasons, not all of which are completely understood. But they center on a DNS resolver library that issues DNS requests directly from the viewer. To solve these problems, we're trying a scheme that uses threads and the normal operating system resolver library.
	If you had this problem and changed your computer's DNS configuration to use Google DNS (https://developers.google.com/speed/public-dns/docs/using) or other DNS service, these changes are particularly relevant to you. We're inviting people who have experienced DNS failures to do some testing of the new scheme.		If you had this problem and changed your computer's DNS configuration to use Google DNS (https://developers.google.com/speed/public-dns/docs/using) or other DNS service, these changes are particularly relevant to you. We're inviting people who have experienced DNS failures to do some testing of the new scheme.

	Revert your DNS configuration.		*Revert your DNS configuration.
	- Restore your DNS settings to their original values. In most cases, this will mean switching back to the values provided automatically by DHCP. Visiting the Google page may jog your memory.		**Restore your DNS settings to their original values. In most cases, this will mean switching back to the values provided automatically by DHCP. Visiting the Google page may jog your memory.

	Confirm that your current Second Life viewer has the DNS problem.		*Confirm that your current Second Life viewer has the DNS problem.
	- Before installing the new viewer, login using your old viewer and see if you get the DNS error above.		**Before installing the new viewer, login using your old viewer and see if you get the DNS error above.
	- If it just works, that's good for you, bad for us: we won't be able to see an improvement. You might leave the DNS settings in their natural form (using DHCP) or go back to Google DNS. Whichever works best for you.		**If it just works, that's good for you, bad for us: we won't be able to see an improvement. You might leave the DNS settings in their natural form (using DHCP) or go back to Google DNS. Whichever works best for you.
	- If it fails to login due to the DNS problem, you've confirmed the original situation still applies and we can move on to the next test.		**If it fails to login due to the DNS problem, you've confirmed the original situation still applies and we can move on to the next test.

	Test the new viewer; confirm correct behavior.		*Test the new viewer; confirm correct behavior.
	- Install and login using this release.		**Install and login using this release.
	- Login and scene loading should work as expected without DNS errors.		**Login and scene loading should work as expected without DNS errors.
	- Teleport a few times and verify that scene load continues without DNS problems.		**Teleport a few times and verify that scene load continues without DNS problems.

	Report test results, good or bad.		*Report test results, good or bad.
	- Tell us what you found in http://community.secondlife.com/t5/Second-Life-Viewer/DNS-problems-at-login-a-possible-solution/m-p/2423913		**Tell us what you found in http://community.secondlife.com/t5/Second-Life-Viewer/DNS-problems-at-login-a-possible-solution/m-p/2423913

	If you experience new problems, please report them in Jira (https://jira.secondlife.com/).		If you experience new problems, please report them in Jira (https://jira.secondlife.com/).
Line 40:		Line 46:
	A few new settings have been added to control the behavior of mesh HTTP operations. We don't recommend changing these settings, they have been set to appropriate values. But special cases may arise and you can try these to work around problems.		A few new settings have been added to control the behavior of mesh HTTP operations. We don't recommend changing these settings, they have been set to appropriate values. But special cases may arise and you can try these to work around problems.

	Mesh2MaxConcurrentRequests		;Mesh2MaxConcurrentRequests
	Controls the maximum number of concurrent mesh download requests issued by the viewer. If you encounter unreliable networks or routers or have a low-bandwidth connection, you might find that lowering this value improves the your experience.		:Controls the maximum number of concurrent mesh download requests issued by the viewer. If you encounter unreliable networks or routers or have a low-bandwidth connection, you might find that lowering this value improves the your experience.

	MeshUseGetMesh1		;MeshUseGetMesh1
	If set to TRUE, the viewer will revert to the original HTTP scheme for downloading meshes. (This also re-enables the old MeshMaxConcurrentRequests setting.) We don't imagine any scenario where this might be needed. But it's available as a possible workaround for unforeseen problems.		:If set to TRUE, the viewer will revert to the original HTTP scheme for downloading meshes. (This also re-enables the old MeshMaxConcurrentRequests setting.) We don't imagine any scenario where this might be needed. But it's available as a possible workaround for unforeseen problems.

	MeshUseHttpRetryAfter		;MeshUseHttpRetryAfter
	Servers are beginning to provide 'Retry-After' response headers for 503 HTTP failures. When this setting is TRUE, the viewer will make use of these headers to better schedule retries of mesh downloads. But there may be circumstances, such as a very high ping-time environment, where it doesn't work as well. By setting this to FALSE, retries will be scheduled according to an exponential backoff rule; the same as is used for texture downloads. If you find that a FALSE setting consistently gives you a better experience, we'd like to hear about your environment. A report in Jira, say.		:Servers are beginning to provide 'Retry-After' response headers for 503 HTTP failures. When this setting is TRUE, the viewer will make use of these headers to better schedule retries of mesh downloads. But there may be circumstances, such as a very high ping-time environment, where it doesn't work as well. By setting this to FALSE, retries will be scheduled according to an exponential backoff rule; the same as is used for texture downloads. If you find that a FALSE setting consistently gives you a better experience, we'd like to hear about your environment. A report in Jira, say.
	}}{{GreenCheckbox\|title=Resolved Issues\|body=* {{jira\|BUG-3058}} "DNS could not resolve host name" caused by F-secure - I cant log into Second Life with WIN 7		}}{{GreenCheckbox\|title=Resolved Issues\|body=* {{jira\|BUG-3058}} "DNS could not resolve host name" caused by F-secure - I cant log into Second Life with WIN 7
	* {{jira\|MAINT-2549}} Viewer mesh loading re-tries are not limited		* {{jira\|MAINT-2549}} Viewer mesh loading re-tries are not limited

Release Notes/Second Life Release/3.6.14.285253 - Revision history

Steven Linden at 21:25, 16 January 2014

Steven Linden: Created page with "__NOTOC__ Category:Release Notes ==Release Notes for v3.6.14 (285253) - Second Life Viewer== {{KnownIssuesHeader}} {{GenericDownloadBox|Release|Released on January 16, 2014.|…"

Steven Linden: Created page with "NOTOC Category:Release Notes ==Release Notes for v3.6.14 (285253) - Second Life Viewer== {{KnownIssuesHeader}} {{GenericDownloadBox|Release|Released on January 16, 2014.|…"