Second Life project updates 31/1: server, VMM, group issues, Windows 10 issues

Baby’s Ear, July 2015 (Flickr) – blog post

Update, July 30th: The updated VMM release candidate viewer referred to in this update is now available: version 3.8.2.303891.

Server Deployments Week #31

As always, please refer to the server deployment thread for the latest updates / news.

• Tuesday, July 28th, saw the Main (SLS) channel receive the server maintenance package previously deployed to the three RC channels, comprising internal server fixes related to Experience Keys, comprising null pointer checkers and a configuration option for the number of Experiences a Premium member can have.
• On Wednesday, July 29th, the three RC channels will be updated with a new server maintenance package aimed at fixing recent group-related issues (see below for more details).

Commenting on the Experience changes in the Main channel release a the Simulator User Group meeting on Tuesday, July 28th, Simon Linden said:

That’s just under the hood, the one-per-account is not changing. Simon Linden: with configurations like that, we have a layered approach … there’s a set of defaults that is fixed with each server release. We also have a way to over-ride it grid wide … which is how we can turn on and off some things grid-wide, without a server update; that’s how we turned on the experience tools when we released it. Now that it’s released, we move it into the default settings and eventually out of the over-ride.

Group Issues

In my last update, I reported that people had started experiencing group-related issues, following the Main channel deployment in week #30. In particular:

• BUG-9725 – Activating a group fails on first selection on Second Life Server 15.07.09.303393 & RC
• BUG-9735 – Unable to Edit Group Parameters after being made OWNER of newly created group
• BUG-9695 – [Project Notice] First attempt at joining a group fails (also happens with current release viewer)

Of these, BUG-9735 has been causing the most upset, as it affects anyone who has their role changed. While their role title will update, they will not gain the powers associated with the role, even after the requiredrelog. Commenting on the issues,Simon explained:

It’s due to some database race conditions that show up in the production servers. I was a bit over-aggressive about moving some queries from the master Db to the slave databases…. Normally our main and slave databases are pretty well in sync … with very tiny delay between them; but if you read from the slave database and do something back into the main one, there can be a window when the data isn’t right.

The curious aspect with BUG-9735 is that a relog is normally required for a person to get the updated abilities associated with a role change; so it is unclear why things are going wrong, as Simon went on to say:

I’m not exactly sure how 9735 would happen … I can imagine failures, but relogs should fix that. A bunch of your group info is fetched when you log in, [so] I’m not sure why that couldn’t be updated correctly.

As noted above, fixes for these issues are due to be deployed to the RC channels on Wednesday, July 29th. Once deployed, it would seem likely that anyone being promoted to a new role will have to be on a release candidate channel region when being promoted & relogging, in order for their group abilities to correctly update. However, it’s not clear if the individual promoting someone to a new role will also need to be on a release candidate channel region as well, so some experimentation might be required.

VMM Update

VMM auto-migration of Marketplace Direct Delivery items commenced on Thursday, July 23rd and is proceeding on weekdays between 21:00 SLT in the evening and 09:00 SLT the following morning. However, it is unlikely the VMM viewer will be promoted to the de facto release viewer in the short-term. The reason for this is that the current RC has an elevated crash rate. As a result, there will be a further update to the release candidate, which is due to appear in the next day or so and which will include a number of fixes to try to reduce the crash rate, including one for BUG-9748.

Windows 10 Issues

There have been some recent SL-related issues been noted against recent builds of Windows 10 which are worth reporting, although their potential for any impact may vary.

Font Detection

In the first, BUG-9759, Kyle Linden reports that CJK fonts (those containing a large range of Chinese/Japanese/Korean characters) are not visible in the viewer. This appears to be due to  moving the default location of the font store for Windows 10. As a result, the viewer requires an update so it can look at the revised location.

Windows 10 / AMD Graphics Driver Issue

The second issue appears to be the return of a problem specific to Windows 10 and AMD graphics drivers first reported in March 2015.  This causes the graphics card name to be saved as garbled text into the Windows registry, with the result that any program explicitly requiring the name of the graphics card in order to run correctly can encounter problems (although those which don’t will continue to run OK). As v3-style viewers are designed to explicitly save the GPU name at log-out (it is stored in the settings.xml file), those using Windows 10 / AMD systems may be affected. This is because the garbled card name gets written to the settings.xml file, along with other global settings applied to the viewer by the user, when logging out. This makes settings.xml unreadable by the viewer at the next log-in, so the viewer fails to obtain information, and so reverts all global settings (including graphics) to their defaults. The issue was first reported in April 2015 (see BUG-9054), but seemed to be resolved with later Windows 10 builds. However, it now appears to have regressed with Windows 10 Build 10240 and  the AMD 15.7 driver (see BUG-9740 and particularly FIRE-16528).

Quite how widespread this problem might be as Windows 10 starts shipping is unclear, so the above should be read as an advisory of possible issues. However, if it does prove to be widespread, note that a fix will be required from Microsoft / AMD; this is not something the Lab and affected TPVs can address. In an effort to pre-emptively avoid at least some of the possible headaches the issue might pose for their users, the Firestorm team have developed a workaround, which is to be included in the upcoming 4.7.2 release. This workaround allows the viewer to load the settings.xml file so a user won’t lose all their global settings. But because the graphics card name remains garbled within the Windows registry (from which it is read by the viewer), it will still be saved as garbled text in settings.xml, and the viewer will continue reset all graphics options to their defaults when next launched until such time as a fix is forthcoming from Microsoft / AMD to correct the registry issue.

 Version Number

A third, and in terms of functionality, trivial issue is that Windows 10 will show as Windows 8 running in compatibility mode in the viewer’s system info. This won’t impact the viewer’s performance, and a fix from the Firestorm team has been contributed to the Lab (STORM-2105), and should be appearing in due course.