Piony Hideout, Lions Hill (Flickr) – blog post



Server Deployments

As always, please refer to the server deployment thread in the forums for the latest information and updates.

There was no deployment to the Main SLS channel on Tuesday, March 31st, due to the inventory issues arising from the week #13 RC deployment – see my update here for details.

On Wednesday, April 1st, all three RCs will receive the same update to the current server maintenance package. This update is specifically aimed at correcting the trash purging issue reported with BUG-8877. However, the fix does not address the issue of inventory fetching hanging if HTTP Inventory has been disabled within the viewer.

This is because the Lab regards UDP inventory fetching as a deprecated protocol path, as indicated by the release notes, and non-HTTP based inventory fetching is now being phased out. As such, it is anticipated the option to disable HTTP Inventory within the viewer is likely to be hidden / removed at some point in the future.

SL Viewer Updates

The Tools update RC viewer updates to version 3.7.27.300242 on Monday, March 30th, bringing it into line with the current release viewer (3.7.26 with Avatar Hover Height).

The Maintenance RC viewer updated to version 3.7.27.300323 on Tuesday, March 31st. also bringing it into line with the current release viewer, and includes fixes for many of the bugs and issues encountered with the initial release of the RC.

Other Items

Diagonal Region Rendering Issues

A fair while ago now (late 2012 / early 2013 in fact), I reported on issues that had been noted with regions seeming to be “missing” when seen from other regions.The problem was originally reported in SVC-8130, which is still marked as “unresolved”, and it had been hoped that fix for SVC-8019 would address the problem as well as dealing with other issues. However, the problem has continued intermittently ever since, with numerous issues marked as duplicates of SVC-8130 being reported, with the issue most recently being seen when looking at regions diagonally opposite Brocade on the Mainland.

The problems are regarded as handshaking / communications issues between region, and are generally resolved through a region restart; although understandably, some holding regions on Mainland are reluctant to request a restart as this can affect multiple other region as well.

Multiple Calling Cards

Most of us are familiar with calling cards in the viewer. They can be obtained by friending someone, or by someone giving you their card (or you giving them your card, and are useful for things like opening people’s profiles from inventory (particularly handy in cases where you haven’t friended someone, and so don’t have to use search to locate them), or initiating an IM conference call.

However, within v3-style viewer they can also be annoying, as they have a tendency to multiple for no readily apparent reason. People can often have a set of calling cards under the Calling Cards folder, which can be partially replicated in the Friends sub-folder, and then fully replicated in the All sub-folder beneath that, for example. Or individual cards can get spawned multiple times across one or more folders for no readily apparent reason.

The problem here is that having a high load of calling cards can generate problems logging-in to SL, where they run out of curl multihandles, causing log-in to hang or for them to disconnect on logging-in. This can usually be solved through … wait for it … disabling HTTP Inventory and then logging-in and deleting them, but this may not be an option in the future (see the notes at the start of this report). Given that calling cards get re-spawned following a re-log after deletion, and can start multiplying again, Oz noted in the SUG meeting that they are now an area “worthy of some study”.

Rendering / Rezzing Failures and the CDN

In week #13 I reported on rendering / rezzing issues being experienced by some people in the Florida / Alabama region of the USA. Since that time, the Lab’s investigations through the CDN provider have suggested the the ISP in question (Mediacom) has degraded the service, possibly due to the volume of traffic coming from the CDN. This was a concern voiced early-on during the CDN implementation, but this appears to be the first time such a move has been confirmed. In the forum thread on the matter, which has seen more input on the situation, Monty Linden has offered some interim ideas that may help users experiencing problems, while also emphasising the Lab is still working with the CDN providers to further refine the service.