Category: SL User Group Meetings

SL project updates Week 21/1: server, viewer CDN change, SL network update

Posted on by Inara Pey

WindWept, Dolly; Inara Pey, May 2015, on Flickr Windwept (General) May 2015 (Flickr) – blog post

Server Deployments, Week 21

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

On Tuesday, May 19th the Main (SLS) channel received the server maintenance package previously deployed to the three RC channel, comprising:

  • Internal server logging changes
  • Back-end system bug fixes
  • Reply-To email changed in postcard sends

As previously noted in these pages, the “reply-to email changed in postcard sends” relates to changing the way snapshots forwards to e-mail are handled. Until now, the Lab has substituted the user’s e-mail address in the “from” field of snapshots sent to e-mail, rather than displaying the “secondlife.com” address.

However, this added to issues of e-mail originating from “secondlife.com” being treated as spam by a/v software and ISPs. With the new format employed with this change, the sender’s e-mail address is given as the “reply to” address in the snapshot, and the “from” is “no-reply@secondlife.com”, thus avoiding the issue of LL looking like spammers who are forging invalid addresses.

There will be no RC deployment on Wednesday, May 20th.

SL Viewer

The week has not so far seen an RC viewer promoted to release status. If there is any promotion, it would most likely be the Layer Limits RC (currently version 3.7.29.301305). The Experience Tools RC viewer is still awaiting the completion of back-end work, while the Attachment Fixes RC (Project big Bird) currently has an elevated crash rate compared to the current release viewer, which includes a crash-on-exit bug, so further work is required on that RC.

CDN Provider Move

The Lab has been moving between CDN providers, and as a result, some people may have been experiencing particular texture / mesh / avatar rendering delays of late. Commenting on the process at the Simulator User Group meeting on Tuesday, May 19th, Oz Linden said:

We’ve just finished moving from one CDN provider to another, and it may take the caches a little while to catch up. We tried to do it gradually in a way that would be minimally disruptive, but when you’re dealing with as much data as we are, there are no perfect solutions.

One of the cases it is hoped the move will assist is with SL users in Florida (and neighbouring states) in the US who use Mediacom as their ISP, and who have found that there have been what appear to have been issues with Mediacom throttling the service at certain times of the day. Preliminary feedback from users so affected who have been involved in testing with the new CDN provider has been positive.

What Goes Through the CDN, And How

During the CDN conversation Oz reinterated the data that is currently delivered to the viewer through the CDN: textures, world map tiles, avatar baking data, and mesh data. In terms of in-world objects, two distinct operations are taking place:

  • Where an object is, how big it is, and so on, comes to the viewer via the simulator, together with the UUIDs fr the relevant objects / textures
  • The viewer then uses the UUIDs to fetch the mesh and texture data directly from the CDN.

As previously noted on these pages, this should mean faster loading of things like textures and mesh in-world, as the data is coming from a CDN node that is “local” relative to you, rather than coming to you from the Lab and through the simulator itself. However, experience is showing that for a small number of people, this isn’t always the case, and there can be situations where mesh and texture loading aren’t what might be expected. However, the Lab continues to try to improve things.

Second Life Network Architecture

Writing on the forums, noted SL photographer Jackson Redstar recently asked meshmaxconcurrentrequests – does anybody know the real setting? In the ensuing debate, Monty Linden offered an updated overview of the SL network architecture.

Monty Linden's updated SL network diagram
Monty Linden’s updated SL network diagram

To borrow from Monty’s explanation:

  • On the left, in red, are pieces of the viewer; on the right, in blue are simhost/simulators and other backend services; at the bottom (green) are new CDN services
  • Solid lines with arrowheads are communication paths, either UDP or TCP/HTTP; dashed lines are legacy communication paths that are now or soon will be deprecated, obsoleted and/or deleted
  • Sold ball-and-stick indicators (e.g. TextureFetchConcurrency) indicate a viewer debug setting and the communication path or paths that setting influences; dashed ball-and-stick indicators (e.g. MeshMaxConcurrentRequests) indicate obsolete debug settings.

Monty goes on to say:

Generally, things are moving in the direction of simplification and less resource conflict.  The mesh and texture HTTP traffic, which is usually the greatest load, tends to part ways with the UDP traffic a few network hops after a user’s router or modem.  Lacking TCP’s throttling mechanism, UDP often wins in a fight (give-or-take the efforts of fairness algorithms along the path).  Allowing UDP to overrun the path between viewer and simulator does still degrade the experience and the bandwidth setting remains an effective tool for avoiding this problem.

Other settings should generally be left alone.  A lot of bad advice was spread around in the community in an effort to work around throughput problems.  We’re trying to undo that history and get back on track with more typical (albeit aggressive) HTTP patterns.

 Viewer Caching

During the Simulator UG meeting, Oz repeated a call he originally made at a TPV Developer meeting recently, asking that if there is developer wishing to volunteer for a “deep dive” into viewer caching, he’d like to hear from them.

While interest list updates made key changes to how the viewer’s cache is used, there are numerous issues which appear to be viewer-side caching related, so a deep investigation into the code could go further towards improving things.

One long-standing issue, which is thought to be caching related, is If someone uses a texture rezzed in-world same texture for a group profile image or their avatar profile image or in a profile pick, the object will never fully load the texture.

So, if you’re a developer willing to looking into viewer-side caching, Oz would like to hear from you.

SL project updates week 20/2: TPV Developer meeting, VMM

Posted on by Inara Pey

Miyagi; Inara Pey, May 2015, on Flickr Miyagi (General), May 2015 (Flickr) – blog post

The following notes are primarily taken from the TPV Developer (TPVD) meeting held on Friday, May 15th, and from the Server Beta meeting held on Thursday, May 14th. A video of the TPVD meeting is included below, with any time stamps in the following text referring to it. My thanks as always to North for the recording and providing it for embedding,

Server Deployments, Week 20 – Recap

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

There was no Main (SLS) channel deployment on Tuesday, May 11th. On Wednesday, May 12th, the three RC channels were all updated with a new server maintenance package, comprising internal server logging changes, back-end system bug fixes, reply-to email changed in postcard sends (see below for more).

Group Chat

The Server Beta User Group meeting on Thursday, May 14th, saw a test of a group chat update it is hoped will fix the issue of some people not seeing all or some chat when the group chat window is open (see BUG-9130). The test appeared to yield positive results, with Simon reporting no unusual event logging. The problem here is that the instances of the problem seem to be so rare, it’s hard to guarantee a small sampling of testers will catch any problems which might still exist.

SL Viewer

[00:15] It has been a quiet week on the viewer front. As noted in part 1 of this week’s report, the attachment viewer (Project big Bird) reached RC status, other than that there has been not additional movement with either the current selection of RC and project viewers.

A further update to the mesh importer project viewer (currently at version 3.7.28.300878) is with LL’s QA team and should be released relatively soon. Updates are also being made to the Viewer-Managed Marketplace project viewer (which is likely to go to RC status once through LL’s QA process) and the Oculus Rift project viewer.

Snapshots to E-mail

[02:22] Commenting at the TPV Developer meeting, Oz Linden gave a little more information on the “reply-to email changed in postcard sends” update deployed to the RCs, indicating this was indeed a fix aimed at preventing snapshot to e-mail being tagged as spam by ISPs and a/v software due to the way they handle the “from” field (see my TPV Developer meeting report for week #17), which had caused the Lab to consider removing the snapshot to e-mail capability.

“Instead,” Oz told the meeting, “we found we could get around that by sending the e-mail differently … So the way it’s changed now is that instead of sending the ‘from’ address as the sender’s address, we send the ‘reply-to’ address; and the ‘from’ address is ‘no-reply@secondlife.com’ … so that ducks the problem of us looking like spammers who are forging invalid addresses.”

This should hopefully negate any need to remove the snapshot to e-mail capability, and retain compatibility with sending snapshots to the likes of Snapzilla and the SLU forums.

Unified Snapshot Floater

[04:40] NiranV Dean, who submitted the unified snapshot floater to LL (and which has most recently been integrated into Firestorm among the TPVs) asked if there had been any feedback on it. Both Oz and Grumpity Linden indicated that overall, feedback has been positive, although some have complained at the amount of screen real estate it takes up with the preview panel open. As this allows the snapshot preview to match the aspect ratio of the user’s screen, there’s not a lot that can be done about it – and the preview window can always be closed / the panel minimised when initially setting-up shots.

The unified snapshot floater - further work is being carried out by TPV devs for contribution to LL, including the possible full integration of the Facebook, Flickr and Twitter upload options
The unified snapshot floater – further work is being carried out by TPV devs for contribution to LL, including the possible full integration of the Facebook, Flickr and Twitter upload options

Niran is proposing a further set of updates (one of which, a fix for auto snapshot, is in the works at the Lab), including possibly making the preview screen detachable from the main floater.  Cinder Roxley also indicated she is working on fully integrating the Facebook, Twitter and Flickr options into the main snapshot floater (they currently retain their own floaters due to the authentication workflow required for each. This work will be contributed to the Lab for consideration / integration when complete.

Viewer-Managed Marketplace (VMM)

[08:09] Over the last two weeks, as a part of the on-going beta of VMM, around 15-20 volunteers have had their stores migrated by the Lab from Direct Delivery to VMM. Brooke linden reports that the exercise has uncovered “pretty much minor issues” which the Lab can address. A further batch of volunteer migrations is planned to help further test the robustness of the process in the next week or so.

As noted above, the VMM viewer is now heading for an RC release once it has cleared LL’s QA testing. However,  the time frame on when this might happen is a little vague; it might be in the next week or so, or it might be longer.

Avatar Complexity

[17:34]  The next Snowstorm contributions viewer is progressing internally at the Lab. This is the viewer which includes the new Avatar Complexity (aka “Jelly Babies” or “rainbow avatars”) functionality which allows users to define a level of complexity (a weighting number) which will render any avatar exceeding that value as a solid colour, rather than a full avatar. The aim of this is to help reduce the rendering load placed on people’s computers, particularly in very busy locations. The value is adjustable, as so can of course be varied to suit your current needs.

Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.
Avatar complexity is intended to help those who may hit performance issues as a result of their GPU struggling to render complex (hight render cost) avatars, by rendering such avatars as solid colours.

A slight hiccup has occurred in that in making some changes to the code, Oz accidentally broke the code such that instead of rendering as a solid colour, avatars exceeding the limit are currently rendering as transparent, and this is yet to be fixed. Code has been added to the viewer to report how many people around you are rendering your avatar as a solid colour (should your avatar be complex enough to be rendered thus), but this has yet to be made visible through the viewer UI, and simulator support for this is now in place on the RC channels and will be rolled to the Main channel in the coming week.

Mac Updates

[19:36] Cinder Roxley has a set of contributions for using the viewer with Mac Retina displays ready to go to the Lab, and it seems likely these will flow into a further Snowstorm contributions viewer in development alongside the one containing the Avatar Complexity updates.

A question was also asked whether there were plans to update the Mac viewer to use a newer OpenGL core profile. The Lab is not working on this, as their rendering team believe there is little or no benefit to be gained from it. However, they would accept any contributions offered for consideration (subject to a “long, terrible QA process”). However, a good part of this would require working through some eight years of OpenGL code.

SL project updates week 20/1: Server and viewer; outfits

Posted on by Inara Pey
Join Hands: raising money to help the WFP's aid work in earthquake-struck Nepal
Join Hands: raising money to help the WFP’s aid work in earthquake-struck Nepal with Fashion for Food – May 13th through May 16th inclusive

Server Deployments, Week 20

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

There was no main (SLS) channel deployment on Tuesday, May 11th. On Wednesday, May 12th, the three RC channels were all updated with a new server maintenance package, comprising:

  • Internal server logging changes
  • Back-end system bug fixes
  • Reply-To email changed in postcard sends

As noted in my TPV Developer meeting report for week #17, snapshots are sent via the “secondlife.com” domain, but use the sender’s own e-mail address as the originating address in the “from” field. This, and other ways ways in which e-mails flowing out from “secondlife.com” are handled has resulted in some ISPs regarding the domain as a spam domain, and have been pro-actively blocking it.

The “reply-to email changed in postcard sends” refer to a change made to how the “from” field in snapshots sent to e-mail (which the Lab refers to as “postcards”)  is addressed in an attempt to alleviate the problem.

At the time this issue was raised at the TPV Developer meeting, it was indicated that the Lab was considering removing the the snapshot to e-mail capability server-side. However, as was indicated in the meeting, doing so would break a number of wardrobe HUD systems which are popular among users. Whether or not this fix is an attempt to address the spam issue without having to remove the snapshot or e-mail functionality is currently unclear.

SL Viewer

Attachments Viewer (Project Big Bird)

The attachments viewer was promoted to release candidate status with version 3.7.29.301361, release on Wednesday, May 13th. This viewer provides a series of fixes for attachment-related issues, particularly when multiple attachments are added or removed at the same time. It also has enhanced logging, so the SecondLife.log file will have some additional lines related to avatar state in general and attachments in particular.

Linux

As noted in a separate report, the Lab have now blogged about seeking assistance from open source developers in the continued development and maintenance of the Linux flavour of the viewer.

 Outfit Folder Changes

A recent change to viewer functionality means that it is no longer possible to drag and drop sub-folders of items into the My Outfits  / Outfits folder – see BUG 9209 (FIRE-15603). This change, which is in the official release viewer, is filtering out into various TPVs, and has been causing some consternation.

While it is still possible to create sub-folders within My Outfits / Outfits and drag and drop items into them, many people have tended to simply unpack new clothing items into a default folder and drag that folder (or the Direct Delivery folder for the clothing) into My Outfits / Outfits, and then sort the contents into suitable outfits from there. Others have used the Appearance floater to create outfits, save them, and then drop them into My Outfit / Outfits – which also is no longer possible.

It’s unclear precisely what problems can occur in allowing drag-and-drop in My Outfits, although it appears drag-and-drop into My Oufits was never intended to be allowed. The change itself was made by Vir Linden, shoe has most recently been working on a range of improvements to try to reduce issues of inventory loss; he is now involved in the JIRA discussion, seeking to understand use cases relating to dragging-and-dropping folders into  My Outfits.

SL project updates week 19: server, group chat, child agents

Posted on by Inara Pey

Ichi-go Ichi-E, Fantasy Faire 2015 Inara Pey, April 2015, on Flickr Ichi-go Ichi-E, Fantasy Faire 2015 (Flickr)

Server Deployments Week 19 – Recap

On Tuesday, May 5th, the Main (SLS) channel received the server maintenance package deployed to all three RCs in week #18, comprising internal server logging changes  and a new flag for llGetObjectDetails()  – OBJECT_LAST_OWNER_ID; plus new data which can be requested  via llGetEnv(). These are:

  • “agent_limit”- get the maximum number of avatars normally allowed on the region (teleport home, and login to last location, are allowed to exceed this).
  • “estate_name”- returns the name of the estate (e,g, “mainland”, “Linden Homes”, “My Happy Estate”, etc. )
  • “region_cpu_ratio”- returns the number of regions per CPU for this region type (i.e. “1” or “4”)
  • “region_product_name” – returns the type of region this is: “Estate / Full Region”, “Mainland / Homestead”, “Estate / Openspace”, “Estate / Full Region – Skill Gaming” etc.
  • “region_product_sku” – returns the region’s product number as a string
  • “region_start_time” – returns the time the region was last (re)started, in llGetUnixTime format
  • “simulator_hostname”  – returns the simhost running this region. Same as llGetSimulatorHostname but without the script delay.

There were no planned RC deployments or restarts for Wednesday, May 6th.

Group Chat Failures

There are been a number of odd group chat issues recently, such as those outlined in see BUG-9130. Simon Linden has been investigating the issues, and gave his findings at the Simulator User Group meeting on Tuesday, May 5th, “Basically the chat server gets stuck with bad info about where the avatar is. The normal ways that would get corrected aren’t working right … but trying to log off and back in, or leave and re-join the group might fix it.”

When asked if a re-start of the affected chat servers could clear the problem, he replied, “possibly … except one of the features of the chat servers is that they try to save everything and re-load it when they come back up.   That way everyone isn’t kicked out of all their group chats when it restarts. I’d have to check but I think they may save the bad info about [the affect avatar]. ”

Group chat messages are routed to you via the region you are in at the time the message is sent. However, if you have moved to another region during the conversation, the region will tell the group chat service you are no longer there, and the service then performs a look-up to locate you so that the messages can again be sent to you via the region simulator. “In this case, Simon explained the current issue, “it’s failing with a different error due to a change in the grid configuration, and not handling it correctly.”

With the cause of the issue now identified, the Lab hopes to get an update out to the chat servers to fix the problem very soon.

Attachment Failures

As has been noted in these updates, the Lab currently has a series of viewer-side fixes for problems relating to attachment issues (items detaching on region crossing / teleporting, items showing as attached when detached or vice versa, etc.) which are  at project viewer status (“Project Big Bird”) and  will be progress through the viewer channels in due course.

In addition to the viewer fixes, there are are some server-side issues with attachments the Lab is investigating. In particular, the Lab has identified that requests for multiple simultaneous attachments at or near the upper limit (38) to be attached at the same time will invariably overload the pipe, although why this is the case still has yet to be determined.

Experience Keys / Tools

Work continues with the back-end of Experience Keys / Tools, and Simon Linden has most recently been working on the key values database for the system (which can be used to store information relating to users who have been  / are engaged in an experience, such as their progress, items they may have collected / attached, etc.). Given the anticipated popularity of Experiences, and the fact that people have already identified other potential uses for the key value database, the Lab is trying to ensure it is robust enough to handle and and all uses it might be put to – and can deal with the potential of poorly-written scripts persistently polling / updating it more than is strictly required without necessarily impacting its performance.

Other Items

Agent Updates, Draw Distance and SL Performance

In discussing the group chat issues during the Simulator User Group meeting, the conversation turned to the matter of agents and child agents. While the region you are operating in has the main connection to your avatar (your agent), it may also be sending information to avatars on other regions, and you may also be receiving updates from surrounding regions.

The status panel (CTRL-SHIFT-1) reveals how many child updates the region you are in is sending elsewhere (31 in this case). some of these might be unavoidable, others might simply be down to people 3 or 4 regions away with ridiculously high draw distances
The status panel (CTRL-SHIFT-1) reveals how many child updates the region you are in is sending elsewhere (31 in this case). some of these might be unavoidable, others might simply be down to people 3 or 4 regions away with ridiculously high draw distances

Simon explained things thus, “while you’re here, you’re also talking to the region next door; it will send you updates about what happens over there … it has a camera for you and knows what you can see, and sends you updates but it doesn’t run your scripts, for example.”

This tracking of what is going on in other regions is determined by an avatar’s draw distance and the direction in which they are looking, and the “camera” Simon referred to in his description is known as a “child agent”.

Child agents help with a number of tasks – the such as allowing you to see what is going on in a neighbouring region, as Simon mentioned, and also assisting with aspects of region crossings.

Obviously, there will be child agent updates going on between neighbouring regions as a matter of course. But when you have an abnormally high draw distance, the chances are that you are having an additional impact not only on the regions immediately adjacent to the one your in, but every region that falls within draw distance / view, as you are forcing them to send you updates as well, and you are forcing the region you are in to work that much harder to pass those updates to you.

Hence why it’s a good idea to keep your draw distance down to a reasonable level (say 256 metres or lower) for as much as you can. You’re not only helping improve your own experience (however powerful your own computer might be) – you’re showing courtesy to those active in the regions around you and who might also be affected by the region they are in having to take time serving data you may not need to your viewer.

SL project updates week 18/2: TPV Developer meeting

Posted on by Inara Pey

Server Deployments Week 18 – Recap

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

SL Viewer

[00:30] All of the viewers currently in the release channel as RCs are currently being updated to match the current release viewer, version 3.7.28.300918, which uses the new viewer build tool set.

Experience Keys / Tools

[02:06] The Lab is still making headway on the back-end issues they wish to clear before they promote the Experiences RC viewer to the de facto release viewer.

Attachment Fixes

[02:20] The attachment fixes project viewer (Project BigBird), currently at version 3.7.28.300856, is expected to appear as a release candidate viewer very soon – most likely in week #19. It is thought this viewer fixes all of the attachment issues associated with AIS v3, although there are some attachment issues which occur server-side which it does not correct, such as failures with requests to attach multiple items (such as during an outfit change).

Oculus Rift Project Viewer

[07:22] As noted in my last TPV Developer meeting report, the Lab is resuming work on the Oculus Rift project viewer. The focus on this will be to ensure the viewer works with the latest Oculus SDK (it is currently running behind SDK releases), and also up to the latest viewer source.

Once this has happened, it is likely that the viewer will enter the release channel as a release candidate viewer, so that it can keep pace with updates to the release viewer, and from there progress to release status. How quickly this will happen is dependent upon a lot of different factors, and it is likely to remain the last in line to become the release viewer for a good while, partly because it is unlikely the Oculus Rift will be available as a consumer item until 2016, and so there will be other things entering the release channel which have broader usage within the SL community, and will therefore be promoted more quickly.

Viewer-Managed Marketplace

There was a Viewer Managed Marketplace meeting on Friday, May 1st, immediately prior to the TPVD meeting, and a transcript of that meeting, with recording, is now available.

SL projects updates week 18/1: server, viewer

Posted on by Inara Pey
UNIA launches at 12:00 noon on Monday, April 27th
MadPea’s UNIA is now open for those of a brave disposition, and uses Experience Keys / Tools

Server Deployments Week 18

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

  • There was no Main (SLS) deployment on Tuesday, April 28th.
  • On Wednesday, April 29th the three RC channels all received the same sever maintenance package. This comprises Internal server logging changes  and a new flag for llGetObjectDetails()  – OBJECT_LAST_OWNER_ID; plus new data which can be requested  via llGetEnv(). These are:
    • “agent_limit”- get the maximum number of avatars normally allowed on the region (teleport home, and login to last location, are allowed to exceed this).
    • “estate_name”- returns the name of the estate (e,g, “mainland”, “Linden Homes”, “My Happy Estate”, etc. )
    • “region_cpu_ratio”- returns the number of regions per CPU for this region type (i.e. “1” or “4”)
    • “region_product_name” – returns the type of region this is: “Estate / Full Region”, “Mainland / Homestead”, “Estate / Openspace”, “Estate / Full Region – Skill Gaming” etc.
    • “region_product_sku” – returns the region’s product number as a string
    • “region_start_time” – returns the time the region was last (re)started, in llGetUnixTime format
    • “simulator_hostname”  – returns the simhost running this region. Same as llGetSimulatorHostname but without the script delay.

Commenting on the llGetEnv() updates at the simulator User Group meeting on Tuesday, April 28th, Simon Linden, who made the updates, said, “these are all pretty simple ones … I went for the easy pickings.  Basically, information we already  sent to the viewer, or was readily available, and thus not a privacy issue.”

He continued, “There was one [further option] for the max number of agents that was in the original list but that one got skipped … not part of a sinister plot but I overloooked it.  want to do some other things with that limit sometime soon as well 🙂 … I’d like to see how the region and viewer performs with bigger numbers. Things go bad with many AVs for a variety of reasons … the server has more updates to send to more people, all wearing more scripts and AOs and HUDS [and] the viewer gets overwhelmed with too many complex avatars and too many textures in the download and graphics pipeline.”

SL Viewer

The Avatar Layer Limits RC viewer updated to version 3.7.29.301305 on April 28th, bringing it to code parity with the current release viewer. This RC allows users to wear up to 60 wearable layers (jackets, shirts, tattoo, alpha, etc.) in any combination – so you can wear 60 tattoo layers with it an nothing else, if you want – rather than being restricted to wearing a maximum of 5 of each type of layer.

Other Items

Online / Offline Indicators

People are noticing that the group chat list (the list of group members in the Group panel), is now much slower to update as people’s status changes (i.e. whether they are on-line or off-line). This is intentional, and comes as a result of the recent improvements made to group chat.

In particular, and as I reported in these pages as work on group chat commenced in 2014, the volume of people logging-in to and out of SL can generate a huge amount of updates for the group chat service (given your status has to be sent to every group of which you’re a member, and to over member of that group who is online to update the group list in their viewer with your new status), meant that more time was being consumed by the group chat servers in handling these update messages than in handling actual messages.  The fix for this problem means there is a natural delay in group list updates, as they are now processed differently to reduce the impact they have on message handling.

However, some people have started noticing that some group chat lists with 20+ members seem to take a very long time to update – times of 5-10 minutes have been mentioned, and this is causing some confusion when seeking things like assistance from group owners / moderators (as they can appear to be logged-in long after they have logged-off). It’s also bee reported that at times the list seems to get stuck with no updates until the group chat itself is closed and re-opened, although this appears to be somewhat intermittent.