The Phoenix team is doing a Phoenix Hour on Rezzed.TV. One gets lots of good information. It does take an hour and there are commercials. All in all rezzed.TV does a good show. You should check one out. Here I’ve included some of the points that interested me.
Phoenix Viewer Top Issues
There are 4 main support issues the Phoenix Support team is seeing. The main one they named ‘Bake Fail’. The symptoms are you appearing nude to yourself or others when you are dressed. Also, when changing cloths you look OK to yourself but to others you are still wearing the previous clothes.
Phoenix’s position is that this is a server issue and all viewers experience the problem. Technically I agree with that position. However, I think there is some spin in there. My experience is TPV users are seeing more of this problem than others. The OpenJPEG/KDU image decoding/decompressing is likely a major issue in the problem. The servers are failing to handle broken texture downloads and broken decodes from OpenJPEG/KDU differences well. There is more information in Avatar Render Problems: Ghost Cloud Smoke Ball Ruth. You’ll have to make your own call on the cause of the problem.
Teleport Failures is another leading problem users are having. The two largest contributors to the failure are wearing a large number of scripts and laggy SIM’s. Sometimes too many prims attached to the avie. Some hair, prim clothing, shoes, and weapons have a high number of scripts in them. So, because of lag we see more of these TP problems on the weekend.
Phoenix has a feature in the right-click-on-avie labeled S. Count. This is script count. It tells you how many scripts are attached to your avie. This should be as low a number as possible. Anything over 200 is almost certain to cause you problems.
The S. Count feature is neat and handy but it is also buggy. It is best used in a deserted SIM. If an avie rezz’s into a SIM while you are running S. Count, you will likely see it fail. Then it will not work in that SIM until you leave and return. I suggest a SIM neighboring Aqua or Pooley.
Viewer Crashes are a big problem for Phoenix users. Jessica points out that most of these problems are computer related rather than viewer related. The only viewer specific problem for Phoenix 225 & 373 is swing your view quickly can crash the viewer. They have found the problem and it will be gone in the next release.
If you need to ask for help with viewer crashes, you need to be able to tell Phoenix Support what it is you were doing when you crashed.
The fourth most common failure is Media Fail. At this time it is a system wide problem. There seems to be no consistency in what causes the problem for some people and not others. However, Jessica thinks they have a fix for the problem and it will be in their next release.
Crash Logs & Privacy
You may know that the SL viewers send crash logs to Linden Lab. You may not realize that the logs contain lots of private information. Of course Linden Lab already has the personal information. But TPV’s do not. For this reason the Phoenix Team decided not to have their viewer send crash logs. That and the room needed to store the logs on their server.
One can include a crash log when they file a Phoenix JIRA. It is added as an attachment, which only the team members can access. If you plan to include the log in your JIRA, remember that each start of the viewer clears the previous log. So, save the log to a new location or rename it before you logon again.
This subject came up again in the Hour. How does one get SLURL’s to work with the viewer of your choice? Jessica recommends just copying the SLURL and pasting it into chat or IM and clicking on it.
Clicking on SLURL’s will typically open the last viewer installed. This is a computer setup issue which is complex for viewer developers to deal with. In general it is left to the user to decide how they want things to work. For some browsers there are work-arounds, for instance Firefox.
Some time ago I explained how to set your computer to use the viewer of your choice. See: Emerald Viewer vs SLURL, which I probably should rename to Phoenix Viewer and SLURLS’s and update. The change requires registry changes.
How transparency in works in SL is a problem. This is supposedly fixed in SLV2. The problem is part of OpenGL and how it is used. Jessica thinks this is not viewer specific. She is right in that most viewers have the problem. However, different viewers show the problem differently. I expect to see this problem fixed as viewers move to series 2.x viewer code.
Ducking SIM Restarts
I found Jessica’s answer not fitting with what is actually being done by the Lab. On Tuesdays and Wednesday there is a lot of new server software rolling out being done. Updates are rolled to the main grid on Tuesday mornings. So, on Tuesday morning it can be a little hard to find a SIM that is not restarting. It can be annoying but in general the grid is getting better.
On Wednesdays the Lab rolls out new software to the Release Candidate Channels for testing. If one looks in Help -> About SL you will see if you are in a region in a Release Channel. Look for Blue Steel, Le Tigre, or Magnum in the server info. If it is there you are in a region what will likely restart on Wednesdays. Otherwise, it will happen on Tuesday. If problems come up, another restart can happen at any time as they unwind the changes.
If Release Candidate testing fails, there is no rollout to the main grid. We only know after the fact what happened. We can figure that the standard schedule is what is supposed to happen.
I suggest one find a Release Candidate region to use for a quick get-away on Tuesdays. If you live in, have shops in, or play in a Release Candidate region, find a get-way in a non-release channel region.