|Anonymous | Login | Signup for a new account||2020-02-18 08:39 PST|
|Main | My View | View Issues | Change Log | Roadmap | Summary | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007403||opensim||[GRID] Asset Service||public||2015-01-06 12:07||2017-11-23 12:22|
|Assigned To||Mata Hari|
|Platform||Intel i7 930 quad core||OS||Windows .NET||OS Version||Win7 x64|
|Product Version||master (dev code)|
|Target Version||Fixed in Version|
|Summary||0007403: Failure to deliver assets to some viewers in a region|
|Description||Per discussion at the last several dev meetings I'm creating this report because I can't locate the original report where I described this behaviour.|
It seems that on occasion one or more assets worn by an agent in a region are not sent to another agent in the region. When this happens the only way the agent will ever receive the asset is to log out and then back in again. If the wearer relogs the asset still never gets sent.
Conditions that appear to make this more likely to occur:
- high region traffic -- I notice it most with 10+ avi in a region
- large asset size -- I notice it occurring far more commonly with mesh, but it will also happen with sculpties and textures worn as attachments
- it seems most common when the wearer is a hypergrid visitor to the region rather than a native avatar but the agent who is failing to see something can be either
- when it happens, it's not consistent in the sense that if I tp into a region where there are already 10 avi and I'm wearing 2 mesh items, many will see me complete, one or two may only see item A and one or two may only see item B
|Tags||No tags attached.|
|Git Revision or version number|
|Run Mode||Grid (Multiple Regions per Sim)|
|Environment||.NET / Windows64|
Mata Hari (reporter)
This also frequently occurs when a new animation is called where the animation is a 30+ second one (hence may take a little while to fetch).
Further testing suggests that the asset *is* actually being sent to the other viewers in the region however the viewer doesn't appear to display it until after a relog. Upon relog, the asset is available immediately so it's being pulled from the viewer cache; but until a relog there is no way to trigger displaying it (tping to another region back doesn't resolve it, nor does wearing something else then rewearing the original item).
Mata Hari (reporter)
|As per http://jira.phoenixviewer.com/browse/FIRE-17105 [^] it would seem that the viewer coders feel the issue resides within Opensim so it's up to Opensim dev to either fix it from this end or supply the necessary code fixes to the TPV coders to resolve it.|
That Jira report refers several possible different issues.
Objects rez does seem to be a viewer side problem
Also there are different types of assets most with own transfer protocols.
This can be common issue, or specific to some assets, and can be viewer side
Sounds are a odd example.
Mata Hari (reporter)
Sounds is one I very rarely encounter or I might just not be aware of it when I do.
Animations happen periodically but almost only with ones that are full 60-sec paired ones. That's when 2 different, matched-set 60-sec animations are called to be played on 2 avi....when they're not in cache there's a delay while they're delivered and sometimes one or both of the avi simply fail to ever start playing that animation. When that happens, you will *never* see that animation play until you exit the viewer and start it again. Switching to a different animation won't do it, not will anything else I've tried. After relog, calling the animation will have it begin to play ~instantly with no delay at all to "fetch" it so I can only assume that it was sitting there in the viewer cache ever since first being called, but for some reason the viewer doesn't know it has it, nor does it re-request it, nor does calling it again (even after an animation switch) get it to re-fetch.
The same behaviour happens with attachments -- mesh or sculptie -- and is far, far more common. Again, that item will never be visible until the person who can't see it exits their viewer and starts it again. Switching to wireframe (which you mention in the JIRA) doesn't "fix" that...it's as though it doesn't exist at all.
There is *something* that happens during viewer start-up that somehow lets it identify that the item is in cache, though, because upon relog the mesh/sculpt will appear instantly without any delay at all to request/fetch the asset from the server.
If nothing else, at least a temporary solution would be some form of "rebake" which forces a viewer to redo whatever that unique start-up operation is so it can pick up the garbled asset(s).
don't know.. does side like cache / dirty flags or whatever viewer side control.
At least attachments I did test and regions do send all its needed.
That rebake is not a option, impossible to know when needed, and could have bad effects if sent when not needed.
|2015-01-06 12:07||Mata Hari||New Issue|
|2015-01-06 12:10||Mata Hari||Description Updated||View Revisions|
|2015-09-08 04:43||Mata Hari||Note Added: 0029458|
|2015-12-01 05:38||Mata Hari||Relationship added||related to 0007774|
|2015-12-31 08:26||Mata Hari||Note Added: 0029897|
|2015-12-31 10:15||UbitUmarov||Note Added: 0029898|
|2015-12-31 11:16||Mata Hari||Note Added: 0029899|
|2015-12-31 12:08||UbitUmarov||Note Added: 0029900|
|2017-11-23 12:22||Mata Hari||Status||new => resolved|
|2017-11-23 12:22||Mata Hari||Resolution||open => suspended|
|2017-11-23 12:22||Mata Hari||Assigned To||=> Mata Hari|
|2017-11-23 12:22||Mata Hari||Status||resolved => closed|
|Copyright © 2000 - 2012 MantisBT Group|