Affects Version/s: None
Fix Version/s: Sprint 12
Environment:Any Viewer 2 since changeset 03bdb3e84ee0 / code suggests platform independent
Branch/Repo Fixed In:
Approvals:Code Review, Product Owner
Acceptance Criteria:Check description for repro: basically, verify that the secondlife.log doesn't show loads of :
INFO: LLMediaDataClient::serviceQueue: Sending request for request: num=9753 type=GET ID=ea1a378d-328f-d024-671e-09da2a2d4dde face=-1 #retries=0
While looking through my secondlife.log I noticed the following:
Those 9753 cap requests occurred over the course of just over 2 hours. The sheer amount of them, coupled with frequently hitting the throttle limit didn't seem normal at all since objects with media on them are still rare and it seemed unlikely to encounter 9753 of them in the same region.
Teleporting home where I knew there shouldn't be any objects with media on them some of the objects the viewer was hitting the ObjectMedia cap for were a "dinner table", a "side table", some plants, etc which very clearly suggests a bug.
S32 LLTextureEntry::setMediaTexGen(U8 media) would appear to be the root cause of the bug:
The header file suggests that:
and while LLTextureEntry::setTexGen() and LLTextureEntry::setMediaFlags() each properly mask off the supplied parameter with their respective bit mask, setMediaTexGen() will always return TEM_CHANGE_MEDIA even if only texgen has changed while the media flag hasn't (causing LLVOVolume::processUpdateMessage() to queue a request to the cap when it shouldn't).
Changing it to:
appears to resolve the issue completely (the cap isn't hit unless an object nearby has media on it, or changes its URL) but I'm much too unfamiliar with that part of the code to judge any impact.
If my viewer floods the cap on a busy region at a rate of about 5,000 request/hour then a full region with 100 avies all on viewer 2 would cause 500,000 needless requests/hour on that region cap so this really could use some "Linden love" .