Cool VL Viewer forum

I hesitate to call this a bug, but it is at the least an unfortunate interaction that I do not seem able to resolve on my own. If the information here makes it possible to narrow down what is going wrong, I would appreciate some guidance. For background, my old modem/router has been a bit flaky, so I replaced it with the ISP's preferred one. Since the replacement, when I use Cool VL to connect to Second Life I experience the following:

• Login is successful; I can see the world and myself, and interact with people in both local chat and IMs. I can move around.
• After around twenty to thirty seconds, my avatar stays stuck in one place, unresponsive to forward or backward movement. I can, however, still spin in place. (By "unresponsive" I mean from the point of view of what I am being shown. Later logins suggest that my movement commands were acted on by the sim, but not presented to me.) Chat continues to work.
• After approximately two minutes I get a message about the region having difficulty, and am logged out.

This behaviour is mostly consistent. At one point I somehow got a successful login that continued for a few hours, and at another I had around seven minutes of time before getting logged out. Two minutes is by far the most common result, however.

At this point, the most likely explanation was firewalling behaviour in the modem. Unfortunately, the ISP's modem (iiNet's BobLite, which appears to be a rebadged Broadcom of some kind) does not have nearly the same usefulness or flexibility as my preferred one, and I cannot even see what packets are being rejected, if that is indeed what is happening. I have resorted to disabling its firewall entirely, but the behaviour persists. Updating Cool VL has not noticeably changed the behaviour.

If using the old modem, everything works (except that the modem has a tendency to reset itself every so often, which is why I want to stop using it). With the new modem, Cool VL logs me out after the two minutes, as described above. However, the latest versions of the official viewer and Firestorm both work smoothly with the new modem (even with the firewall enabled), so presumably they are doing something different that bypasses whatever the conflict is.

The full log is attached (note that the viewer does exit cleanly rather than crashing, so there is no crash dump). The following lines seem likely to be relevant:


I am guessing that there is UDP traffic from the sim to the viewer being rejected by the modem, even with the modem's firewall disabled. (I further guess that this is due to stateful packet inspection, and the modem does not think that the viewer has established a connection, but I cannot get any useful information out of the modem to confirm or deny this.) And I am bemused that only Cool VL manages to trigger this behaviour.

So, are there further diagnostic steps I can take to determine what is going awry?

This is indeed not a bug in the viewer but rather a poor, so-called "router" (i.e. a router that can't handle enough simultaneous circuits): every true router shall be able to handle the full range of 65536 simultaneous circuits, but some cheap "routers", especially WiFi ones, can't handle more than a few dozens !!!

The difference with other viewers could be due to either a setting in your firewall (make sure that your firewall does allow UDP traffic at all for the Cool VL Viewer !), to a non-standard (non-default) setting you changed in the Cool VL Viewer (do verify that the HTTP texture fetches are enabled in "Preferences -> "Network & Web", that the GetMesh2 capability, HTTP inventory fetches, Web map tiles, and HTTP group data fetches are all enabled in "Advanced" -> "Network"), or to the slightly more aggressive defaults used by the Cool VL Viewer (try reducing the number of simultaneous HTTP texture fetches from 12 to 8 in the "Preferences -> "Network & Web" tab). Also make sure that the Mesh2MaxConcurrentRequests, MeshMaxConcurrentRequests and CurlMaximumNumberOfHandles settings are set to their default value (respectively 12, 32 and 256).

To make it even easier on your (lame) MODEM/router, you could also reduce yet more (in this order of preferences) CurlMaximumNumberOfHandles (down to 128), Mesh2MaxConcurrentRequests (try 8 and down to 6), the simultaneous HTTP texture fetches (try 6 and down to 4). You may also try to reduce the draw distance, to lower the number of neighbourhing regions the viewer will try to connect to (this could also be an explanation for the difference seen with other viewers if you used lower draw distances in them).

Also avoid multi-tasking the viewer(s) with other, circuits-hungry applications (such as a Torrent client) with such cheap routers...

Note that when connecting to an OpenSim grid (these grids don't (yet) have support for HTTP fetching capabilities such as GetMesh2), the problems will get worst (more UDP traffic/circuits in use, more circuits-hungry HTTP algorithms, such as GetMesh).

But my final advice is: get a TRUE MODEM/router.

Thank you for your response. As you pointed out, the default draw distance was different in the other viewers; I lowered it to 64m in Cool VL and got around seven minutes of connection the first time. (I'll note that this was in a sim with no adjacent regions.) If the modem can only sustain a certain number of connections (as you suggest) then it would explain why turning off the firewall was not effective.


These behaviours are with the firewall disabled. The HTTP Texture Fetches, GetMesh2, HTTP Inventory Fetches, Web Map Tiles, and HTTP Group Data Fetches were all enabled. Mesh2MaxConcurrentRequests was at 8, MeshMaxConcurrent Requests at 32, and CurlMaximumNumberOfHandles at 256.

I tried reducing CurlMaximumNumberOfHandles to 64, Mesh2MaxConcurrentRequests to 6, and Max HTTP Requests to 4. I was later able to sustain a connection for over twenty minutes with those settings while doing limited activity in SL. (And could feasibly have been longer -- I had to log out at that point.) However, during an earlier test with those settings I encountered the same issue (lack of movement, then logged out) while in the vicinity of a certain sculpture that consistently lowers frame rate.

(Firestorm carried on happily regardless, with no changes to default settings, mind you.)


This is good advice. I'm rather vexed with this one.

Thank you again for your response.

64 is too low for this setting (and you will probably see warnings about lack of "free Curl Easy handles" in the log, that in the end will lead to a disconnection). You should keep is at least at 96.

I don't mind... The Cool VL Viewer is geared at advanced users ("power users"), while Firestorm is geared at "everyone". The former uses more aggressive settings than the latter, more optimized (but nonetheless stabler) code, geared towards higher performances on properly configured (but, interestingly, not necessarily more powerful) systems... They are different viewers for use by different users, and yes, I do assume the "elitist" stance associated with my viewer: I actually do take pride in being an elitist among computer users (and this even with "old" computer hardware: "elite" doesn't mean more expensive or more modern, but "low quality" is definitely a no-go for an elitist).

That's definitely the best solution since a cheap ("cheap" as in low quality/cut down) router will always end up being a handicap at some point, whatever software you will be running.

Just to confirm: I have replaced the modem with a better one and everything is working satisfactorily again. Thank you again for your quick and accurate diagnosis (and helpful workarounds).