Aishagain

Last week and this, Sayrah Parx kept us informed of the likely changes to Second Life Server code. Last week Lucia Nightfire published an insight to the Server Users Group's rather one-sided discussion of the apparent decision of Linden Lab to end the more-than-decade long tradition of posting Deploy Plans in this forum. I was left with the overwhelming impression that many, if not most, Lindens utterly fail to see the value of keeping the users (or customers, you choose) informed of the upcoming Deploys. There are some who consider that a waste of their valuable time. As a paying customer (yes I pay for my account(s) and so I AM a customer), I found the information valuable, not least if the test deploys to Aditi are flagged up. I cannot spare the time to attend SUG meetings and only a tiny fraction of the SL userbase could attend even if they wanted to.do so. Over the years and with varying degrees of snark I have questioned The Lindens' motives. This particular omission seems to me particularly wrong-headed. A company that cannot be bothered to keep the mass of its userbase informed is very out of touch, it seems to me. I wonder which particular focus/special interest group assists the Lindens in providing the mass of SL with the facilities and features that they want?

Hmm getting a "Server not Found" error on the link for the possible Wednesday roll, Sayrah, the other link is good. I think the link is too short. I can reach the second server code via the first one but the release notes are inconclusive saying "configuration changes for content updates" whatever that means! PS the links to that software version that you published last week are still good for it too.

From my entirely unrepresentative experience, the slow loading of BoM layers, which I see a lot has become an increasing problem over the past few months. The considerable improvement to the viewer rendering pathway has made little or no impact on that. We now get better FPS but avatars remain clouded and the non-standard UV of Lelutka evolution heads give cyclops backwards heads all for longer. It cannot be all down to poor Internet/computer, so I wonder if the CDN is up to the job?

On thinking about Rider's response, it does rather look as though they either don't want to (or don't think there's a need for) post(s) on this thread any more.

@Kat Kassner, just throwing out a suggestion: you don't use a VPN or some other anti-tracing software do you?

This issue is the result of a corrupted file within your settings. I have only heard of the issue in Firestorm but the same issue is likely to occur in the LL viewer's settings folder. Precisely WHICH file I cannot recall but there is an article giving procedure details in the FS wiki and the analogous process would apply for the LL viewer. ETA: I think this is the link to the relevant part of the FS wiki: https://wiki.firestormviewer.org/fs_stored_passwords?s[]=fs&s[]=cannot&s[]=decode&s[]=credentials I see re-reading your post that you have done the first advice given regards the bin_conf.dat file so maybesome of the other suggestions may be relevant?

Thanks @Monty Linden. Sayrah supplied the basic info but a little "awareness raising" would go a long way!

Please, Linden Lab, can we have some information on the status of the Release Candidate channel rolls for today? @Monty Linden, can you help? Recent rolls to the RC Channel have been partial (Bluesteel only two weeks ago, with promotion of that to the whole RC Channel last week and to the rest of SL yesterday) and without any "official" acknowledgement in this forum. Were it not for folk like Sayrah and Logan we would not know unless we were at the relevant Server Usergroup meetings. PS: I only ping Monty since he is one of the few Lindens that participates regularly in these fora.

@Sayrah Parx thanks Sayrah, I'll be glad to check this one out just as soon as I can, my region seems to be taking a long time to restart. I'll be knocking on Support's door soon. ETA: looks like the roll started late today, that's probably why. It was.

@Jackson Redstar this issue has been lengthily debated in a couple of threads in these fora, both this one and the viewer forum. I'll put the links up shortly when I get on my PC since my 'phone won't let me post links. ETA now I'm on my PC, this: and this, though not necessarily related: and for good measure I raised a FS JIRA though the devs at FS seem unwilling to comment, so far: FIRE-32868

The Server version recently promoted to the whole of the RC Channel: https://releasenotes.secondlife.com/simulator/2023-04-21.579747.html is only one of a raft of changes that LL intends to correct the issue with the status on avatars being incorrectly relayed to accounts as they log in. They appear to have corrected the bug whereby all online friends are flagged as offline if a friendship offer is accepted. It is a very partial solution to the overall issue of "agent presence" as they like to term the data. Qie Niangao quotes Rider Linden at the last Server User Group: "[2023/05/02 12:04] Rider Linden: So. Kicking things off in Simulator news. Today we just bounced the main channel, so nothing has changed there. [2023/05/02 12:06] Rider Linden: Tomorrow morning we're going to be expanding the new simulator to the rest of the RC channels. We'd hoped some of the changes there would have helped with the online friends issues, but it would seem that there are still some issues there. [The perennial interminable interchange about troublesome teleports and region crossing ensues, interminably.]"

As far as I recall "copy" then "paste as link". The link will not show to you but will be seen and can be used by others. I've done it a few times myself but not recently. I don't think the procedure has changed.

I'm wondering about raising a fresh JIRA submission about this issue, since several of my friends have seen it recently. I use Firestorm and I know LL will not take my submission seriously unless I see it on the default viewer. The issue is unpredictable and using the LL viewer long term is impractical for me. So, @Phillip Gateaux, which viewer were you using when this issue struck?

Goodness this is an old serverside bug! I had an instance of it just a day or two ago, my partner utterly vanished from one side of a pillar to the next. It's some kind of communication fubar between the sim-server/region and the viewer, which just stops registering their presence in view. You can chat with them, their avatar is locateable via the radar you can even TP to them, but you see neither them or their tag! It has no correalation to the number of avatars on the region. More often than not TPing out from and back to that region refreshes their presence in your viewer but in extreme circumstances you may need to relog. I recall that simply TPing within a region has no effect. I thought that had been worked out of the system but perhaps one of the recent code changes made to the server software has reverted it.

Topic>thread...yes I get it now. As to why do I create the topics? Once upon a time a Linden would post the details of the week's upcoming roll plans, so that those interested would see what or if new code was coming to their neck of SL. That was the "Deploy Plan for the week.....". Most found that informative, even useful. If something went awry as an unforeseen result of the new code they might post a response to the topic and thus create a thread (you see I do get it) or if they are troubled sufficiently and wise they might also create a JIRA entry to report it directly to LL. For some time those posts have either ceased or been greatly delayed, with no obvious reason given. Mazidox or Maestro Linden, I forget which, even admitted they'd been remiss and promised the situation would improve. Unfortunately it has not. My reason for posting the topics was simply to disseminate the roll info as soon as I could in the absence of official word and Logan Elf, among others, added the info as soon as we, the users, found out. Apart from getting myself in a semantics tangle with one or two, I seem to have been elevated to the status of trolldom. That being so I cease forthwith and hope that the information finds its way into this forum by other means.

Strange, then that when I create the initial post I am told that I am creating a new Topic, not a new thread. Also any reply here is apparently a reply to the topic and not to the thread according to the header. In my innocence I'd assumed that LL would know which was which. Anyway I have quite lost the thread and so far as I am concerned the topic is now closed!

@Love Zhaoying No. What I created was a new Topic in the Second Life Server Thread of the Technology Forum. You have it backwards.

Just a "bounce" restart again for the Main Server regions today. The Lindens appear to have abandoned any pretence of posting restart information in this thread. Shame. The only reliable source of information now will have to come via those able to attend Server User Group meetings, such as Inara Pey or Logan Elf, I suppose.

@Nanette Nova take a look at this thread: This seems to be a phenomenon suffered by both AMD and NVidia GPU users in a variety of ways. Some of the advice, mainly that of @Henri Beauchamp may be of some use to you.

Well, I've TP'd around a fair bit this UK afternoon and I have only seen 579248, so I guess the planned deploy to RC Channels was a very limited set of regions. Two of the regions visited were definitely RC channel until very recently, so I think my guess is valid. I don't think the fact that my home was restarted twice yesterday is significant, it has occurred before, so it is no cause to get out my crash helment. ETA: Ahh Logan was adding info while I typed...presumably none of the places I go are Bluesteel!

@Henri Beauchamp thanks, but your answer has two "firsts" and I am unclear as to which I am likely to have on my bios. I assume the "above 4G decoding"? My PC is over 3 years old so I assume it won't have the other setting. The effect I am seeing almost certainly involves incidents of swapping into system RAM. Disabling the dynamic texture memory setting results in quite a lot of texture thrashing but does eliminate the stutters and freezes ( I have tested it during making checks for the FS Jira, FIRE-32868, I raised) but I guess I'll just have to live with that.

Well, I haven't the foggiest notion of the details of what you say @Henri Beauchamp, but that phenomenon does occur when texture VRAM use exceeds 4GB, and at a couple of dance clubs I can fill the texture memory with a 64m dd in less than 30 minutes. Camming around then definitely provokes the long stutter/freeze effects. Having said all that, what can I do about it? My GPU has 6GB VRAM and the dynamic texture memory setting of FS allows me to use 4GB, should I reduce that and if I did won't that promote texture thrashing?

This issue of high RAM use in Firestorm is something I am currently trying to assess. I sometimes encouter FS using in excess of 8GB RAM, and while my GPU (NVidia GTX1660Ti) has 6GB VRAM, I find that Firestorm not only uses a LOT more RAM in a given location, it seems unable to detect the full 6GB, starting to swap to system RAM at anything over 4GB, which is the value set by the viewer as MINIMUM texture memory if I use the Dynamic Texture Memory management in the viewer. It almost seems to regard that 4096MB value as not the MINimum VRAM availablr to the viewer but the MAXimum, above which my system RAM is deployed (I have 32GB of 3200MHz RAM on my system which is substantially more than I am ever likely to use). Now that "spillover" into system RAM is not a problem capacity wise (I have never seen the viewer use much more than 8GB), it causes stutters if I actively cam around at a busy venue (such as at a poplular club. Setting a lower quality is actually counter productive under "high" and I always use the Advanced Lighting Model. So far I have NOT observed such issues on the Linden Viewer, though setting that horrible device up has given me the heebies, and since you cannot set dynamic memory management up in the LL viewer (or at least I'm not able to find the setting in debug), the comparison is invalid. I should say in addition that I have used FS with dynamic texture memory deactivated, and while I see no stutters I get substantial texture thrashing, though not of moving textures, ie those attached to avatars. So far I have no solid conclusions and the support team at FS, while being initially helpful, have added nothing to my understanding of the phenomenon. ETA: By the way the 1660Ti is my ONLY GPU. FETA: Using the latest Linden Viewer (6.6.10) I observe the viewer uses a LOT less RAM in a given situation but due to the ridiculously low level of texture memory this viewer uses (512MB) which cannot be increased via Debug (I tried), the texture thrashing observed was considerable but over a short test in a challenging scene no stuttering was observed.

@Paul Hexem You don't annoy me, Paul, I am simply at a loss to understand why: 1) You never actually characterised the nature of your "crashes" preferring, it would seem, to raise further red herrings. 2) You discount or ignore several others' clearly different interpretations of your experience. 3) You appear to discount the assertions of others that your experience is neither widespread nor considered critical, except perhaps to yourself. Your experience is valid as it stands for you personally, but apparently no reasonable explanation is acceptable to you.

I wish you would