Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007403opensim[GRID] Asset Servicepublic2015-01-06 12:072017-11-23 12:22
ReporterMata Hari 
Assigned ToMata Hari 
PriorityhighSeveritymajorReproducibilitysometimes
StatusclosedResolutionsuspended 
PlatformIntel i7 930 quad coreOSWindows .NETOS VersionWin7 x64
Product Versionmaster (dev code) 
Target VersionFixed in Version 
Summary0007403: Failure to deliver assets to some viewers in a region
DescriptionPer 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
TagsNo tags attached.
Git Revision or version number
Run Mode Grid (Multiple Regions per Sim)
Physics EngineBulletSim
Script Engine
Environment.NET / Windows64
Mono VersionNone
ViewerFS 4.6.8
Attached Files

- Relationships
related to 0007774new Complex avatar with mesh parts fails to complete HG teleport 

-  Notes
(0029458)
Mata Hari (reporter)
2015-09-08 04:43

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).
(0029897)
Mata Hari (reporter)
2015-12-31 08:26

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.
(0029898)
UbitUmarov (administrator)
2015-12-31 10:15

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.
(0029899)
Mata Hari (reporter)
2015-12-31 11:16

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).
(0029900)
UbitUmarov (administrator)
2015-12-31 12:08

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.

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker