Cool VL Viewer forum

Thank you. The change will be part of tomorrow's release, and we will then see how it fares in the long term...

Well, this could be due to the fact that any folder with broken links is now force-fetched just after login (when the inventory cache is read from)...

The changes massively reduced the issue. But rarely it still happens.

From time to time, i still get some instances of this issue, especially when changing outfits and the logging in on a different computer.
The attached log has one such incident again from yesterday evening, i logged out in the afternoon with one computer and logged in later the evening with a different one (and different Cool VL Viewer version, the later one had the newest version). But i cannot really spot any glaring issues besides some cef folder cleanup issues and some RLVa toys misbehaving after login.

Whats peculiar is, that it most often affects certain items with near 100%, the basic layers like skin, hairbase, eyes, shape, physics layer, tattos. All from the same folder (basically my basic shape/look setup folder), also often other items from the same folder are fairly frequently affected, nearly always the same.

And then some random other items from other folders, like shoes etc.

Could it be some issue with that certain folder and just copying all the items (=> new UUID) and creating a new folder has a chance to fix such mishaps?

There could be an issue (a bug in the code) with non-matching (outdated) inventory cache... However, I do not see any related warning in the log.
Did you try to manually delete the inventory cache files before launching the viewer for the first time after you switch to another computer ?

The dropped UDP packets warnings are abnormal (and I never experienced them myself)... With the new LLPacketRing code, UDP packets "in excess" during a frame, are queued until they can be processed on next frame (instead of being dropped at once like they were with the old code), and packets are dropped only when the queue is full; a low frame rate could cause this, but yours is normal...
Maybe you receive UDP packets in large bursts instead of a continuous flow, which could be caused by an inadequate packet buffering in a network router on the path between the sim server and your PC (maybe an inadequate QoS policy, the router not flagging properly UDP packets coming though the ports used by SL servers as needing to be passed through without delay and without buffering)... In any case, this might cause issues, even though the inventory updates now go through HTTP (i.e. TCP, not UDP) in SL. Examining your network traffic with Wireshark might allow you to confirm or deny this hypothesis.
You could also try and compile a viewer with a larger packet ring queue: the relevant line is constexpr U32 MAX_BUFFER_RING_SIZE = 1024; in linden/indra/llmessage/llpacketring.cpp (line 118). I could make this into a configurable setting too...

In the event the bug would be triggered by an outdated inventory cache file, the change in the version of the folder could be the cause for the mismatch; this version is an ordinal number incremented each time something changes in the folder (item moved, removed, added, renamed, inventory link created or deleted, etc)... Are these folders subject to such changes ?

No, i did not try that. It happens so rarely these days that it is hard to reproduce obviously. But yes, in theory this could be a reason.



I'll take a look at the network. It might be bursty, due to some asymmetry in the local network, it is a little bit over kill network for my home.

ISP <= 100/40 MBit/s (Down/Up) => AVM Fritz Box <= 1 GBit/s wired => Netgate 6100 Firwall (pfSense+...) <= 10 GBit/s => Switch <= 2.5GB/s => Desktop.

This should easily handle the UDP traffic. I checked my older logfiles and did not see that LLPacketRing::drainSocket appear in any other. But its a fairly new message, so this is not unexpected.

I'll try recompiling with 8192 max ringbuffer size, and see if anything gets dropped.



Those folders are static for months and longer. I do not include its part in Outfits i save either, so it should barely ever change. I sometimes do not wear all the items, but the content of the folder itself stays static. My point was more, if there is anything special with those base layers, that would make such failures more likely?

Well, the "Fritz Box" or the pfSense router/firewall could be the culprits, if they implement an inadequate QoS for UDP packets on "exotic" ports (12000-13000) such as the ones used by the SL viewer...

Let me now what buffer size works for you...

Nothing special, no... Seen from the inventory items fetching point of view, they are items like any others...