Henri Beauchamp

Ask to your ISP whether your connection is a ”full stack” one (with all 65535 ports available) or not. If it is, the problem is elsewhere, if it is not and your available ports range is limited, either ask for a ”full stack” IPv4, or ask what ports range is allocated to you, and choose one port number within this range to configure the viewer UDP listener port.

Static or dynamic IP, it does not matter: if this is a port range limitation, it won't change a thing...

This could be a limited port range issue... To make for the IPv4 addresses shortage, some ISPs (seen with Free/Illiad in France) are configuring their routers to share a same IP between several of their customers, attributing to each of them only part of the available 65535 ports, e.g. port 1-16383 to customer 1, 16384 to 32767 for customer 2, 32768 to 49151 for customer3, and 49152 to 65535 to customer 4: if you are ”customer 1”, you are in luck and got the privileged ports in your attributed slot, but others will be in pain (especially when they host a server at home). With SL, ports 130xy are needed, viewer side; if your ISP routes them to another customer, you are hosed ! If you are in this case you may however configure the port used by the viewer for UDP (in the Network tab of the Preferences for most viewers), and you could also request a ”full stack” IPv4 from your ISP (they might make this a paying service, however)...

Try setting ”RenderSkyAutoAdjustHDRScale” to 1.0 instead of 2.0... Yup. Please see BUG-234564 and this post of mine about it. For these reasons, I did not yet port the culprit commit/changes to the Cool VL Viewer...

I warned them that it would kill the experience for people with ”weak” hardware... To their defense, LL's developers did try hard to optimize the renderer, but this is totally insufficient for ”old” hardware, like I anticipated (they even had to turn off HPDi for macOS, so bad are the frame rates with it). The good news is that, since my plea to preserve at least the forward renderer got ignored, I decided to implement a dual-renderer in the Cool VL Viewer (currently implemented in the v1.31.0 branch) :you can still use the EE renderer (in both forward and deferred (AKA ALM) modes) or the new PBR renderer, to your heart's contempt, and with just the ticking of a check box in the Graphics preferences (the switching happens in real time: no need to restart the viewer). I intend to keep maintaining this dual-renderer for as long as the PBR renderer will not be fixed (many graphics glitches still exist in it despite the (hasted) push to the ”release” status) and made faster... Or until LL comes up with a Vulkan renderer (whichever will occur first). This means you can keep enjoying SL for at least a little more time... 😉

This is Cloudflare's fault again (this thing is a total nuisance)... However it only repeats the check once for me, then allows redirection to the website. Usual suspect for failures with Cloudflare are: Disabled Javascript in you browser. Disabled Cookies in you browser. Unknown ”User agent” sent/advertized by your browser to the site. This sadly also badly impacts many ”confidential” (rarely used) forks of common browsers.

@sarcmp You could also try and log in with the affected account using the Cool VL Viewer; its inventory code is much more robust to ”unsuspected” issues and won't bar you from logging in. After login you could then try and repair your inventory: from the ”Inventory” floater, ”Folders” menu, choose ”Consolidate/restore system folders”, then log out and retry a login with other viewers. Note that the new inventory thumbnail code as implemented by LL (or more exactly the updates to the AISv3 inventory protocol that accompanied it) can result in this sort of issue as a missing system folder causing failures to log in (because they do not use any more the legacy UDP folder creation message that was synchronous and could solve missing folders issue by creating them in a ”fire and forget” way, instead of needing a callback after creation, callback that cannot be honoured during the login process).

You simply did not install gstreamer... Please, have a look at the installation ”howto” for your OS (e.g. Linux, Windows).

Can't help it: I'm of the ”plug and play” type... 😛

Good news: I don't ! 😜

Another stupid stance by Apple... Not the first, sadly, and likely not the last such stupid stance either, dishearteningly...

Likely a race condition between the two regions you are crossing to when in a corner and moving to the opposite region on the diagonal. As I guess it, the race could be as follow when, e.g. you are in region A and you walk NE to region B that you want to reach, and there's region C, North of A and West of B: you cross the corner and shortly get into C and from there cross to B. Normally, you would get: CrossedRegion sent by departure region A with destination region C. Region A hands over to C (server to server messaging). CompleteAgentMovement sent by the viewer for region C. CrossedRegion sent by transit region C with destination region B. Region C hands over to B (server to server messaging). CompleteAgentMovement sent by the viewer for region B. But, what may happen, due to variable region ”ping” time with servers and reactivity (depending on their load), and the moment they are when receiving the messages during their frame (start of frame: message taken into account immediately, middle of frame and message processing delayed to next frame), you could actually get: CrossedRegion sent by departure region A with destination region C. Region A hands over to C. CompleteAgentMovement sent by the viewer for region C. CrossedRegion sent by transit region C with destination region B. Region C busy re-serializing the agent data it just de-serialized but must still update before re-sending to next region, meaning likely a one frame delay. CompleteAgentMovement sent by the viewer for region B. Message rejected by region B, since no handover was received for this agent yet... Region C hands over to B (finally, but after the viewer sent its own message !). Region B confused: where's that agent ?... Why did not I get its CompleteAgentMovement ? Of course, this is just a wild guess... But it could be fun to try and work around this guessed race condition to see if the hypothesis is correct. Viewer-side, we could try two things, when two region border crossings happen in a row: Delay the second CompleteAgentMovement a little bit (say, by 250ms, or a ”ping” delay + one region frame (20ms)). Send a second CompleteAgentMovement to B, if not ”hearing” from it after a couple seconds...

The effort is not vain, by far: even though Rosetta does a good job running x86_64 apps at decent speed, it cannot perform as good, when it translates x86_64 optimized code into aarch64 code, as what a proper optimizing compiler would obtain when compiling from sources into aarch64 binary... For the SL viewers, however, and since they use OpenGL, and since the latter is implemented like sh*t by Apple, the bottleneck at the GPU level is what drives their performances, far more than the C++ code optimization level.

It does, sort of, for Apple Mx, since those GPUs were only designed to run Metal, with an entirely different architecture as what a GPU designed for OpenGL can do. You end up with ”translated” OpenGL primitives into ones that can be implemented with Apple's custom GPU hardware architecture... OpenGL has always been implemented like utter sh*t by Apple, resulting in extremely poor performances for OpenGL apps on Apple hardware, while the latter usually got quite capable CPUs and GPUs... Beside, and AFAIK, there is not even a native aarch64 OpenGL driver for Mx... But I could be wrong here.

I am curious about how he got a native macOS ARM build (and how truly ”native” too)... The viewer contains SSE source-level code that can only be ”translated”/adapted via specific libraries (such as sse2neon), and he would have had to rebuild for ARM64 all the third party libraries used by the viewer as well... This is totally doable, and a couple contributors to my viewer and myself did it (for Linux only, so far). But it is not trivial either. However, AFAIK (but I am not a Mac specialist, by far: I do not even own a Mac and just toyed with Hackintosh x86_64 virtual machines, which cannot even run a viewer, but can still build it), there is no access to the OpenGL API for native ARM64 macOS builds, making it even more complex a task to compile a truly native SL viewer for macOS Silicon... So this gets me even more curious/perplex... 🤔 This is because, under ARM64 macOS, the bottleneck will be at the OpenGL emulation level, not at the C++ code one (be it ran from native aarch64 binary, or ”translated” via Rosetta from x86_64 to aarch64). Note also that Rosetta is not exactly an emulator: it is a dynamic binary code translator, taking a x86_64 piece of code it runs for the first time, translating it into its aarch64 (ARM64) counterpart, and then running the said translation for any further occurrence of that same piece of code: this is extremely efficient for speed (waaaaay less for memory consumption) after the first run (and you do not really care about the high inefficiency of the first translation run for pieces of code that will never be ran again). The same kind of translator exists under Linux (e.g. Box86 and Box64).

Try installing from a DVD, then (it's usually what I do anyway).

Wait... USB is just for installation/upgrading. Booting and running an OS from it is too slow (and prone to USB memory failures/corruptions: these prmitive and cheap NAND USB memory chips do not have a high endurance neither a ”clever” controller to spread writes over the whole memory and swap faulty blocks with reserved ones, like what happens on SSDs) ! Just install a dual (or triple: Linux +Win7 +Win1x) boot on your hard disk or SSD. Linux can do this just fine for you.

Did you try Rufus ? FYI, my oldest still running PC is based on a Core2 Quad Q6600 (OCed @3.4GHz) with 8GB RAM (and a purely BIOS, non-UEFI motherboard) and a GTX 460, and it does run Windoze 11 (in excess of Linux and Win7 which both run SL viewers much better and faster than Win11, with a blatant (+20% fps) advantage under Linux)...

Here you go: for its 16th birthday, official Cool VL Viewer ARM64 Linux builds. Note: for such a build to properly run on an SBC, you will need proper Panfork support for your GPU (if it shows ”LLVMPIPE” in the About floater, you do not have it and it would be unusable since waaaay too slow).

I still suspect a timeout due to an unreplied server message, here... If I were you, I would log all server messages and see whether my viewer does reply all of them.

Or of a missing reply to some other server message, causing the said server to ”pause” messaging to your viewer, waiting for it to reply before finally timing out on the latter and continuing with the rest of the queued messages... Yes, and it is still in use (even though all the asset and texture reserved bandwidth it accounts for should now be removed both viewer and server sides... A work for @Monty Linden ? 😜); this also means (and contrarily to an SL urban legend about supposed bad effects of a large UDP bandwidth setting) that you can now use a much larger bandwidth number (only part of it will be used for objects data, anims start/stop, etc, anyway). I personally use 32Mbps as a setting (I'm on an FTTH link) in the Cool VL Viewer (which defaults at 8Mbps).

What viewer are you using ?... Why is is so difficult for people to give proper clues for the problem they encounter ? 🤣 I suppose (wild guess, by lack of information), that you viewer is not PBR-enabled and did not recognize the new Materials folder as a ”valid” system folder. Make sure you are using a PBR-enabled viewer if you want to test PBR/GLTF materials. There are currently four of them (by order of appearance/availability): LL's PBR RC viewer. Alchemy beta viewer. Cool VL Viewer, experimental branch (v1.31.0). Firestorm PBR alpha viewer.

Just a wild guess, but are you replying to ”StartPingCheck” with ”CompletePingCheck” too ?...

Went there, all four regions come up and everything rezzes in less than 20s. Here is the relevant log info with milliseconds accurate time stamps and UDP messages debugging enabled (repeated, irrelevant messages removed for clarity); maybe you will find what is missing in your viewer/servers communications.... But you could learn a lot by yourself via the use of the Cool VL Viewer logging features (that's how I managed to make threaded object cache reads work flawlessly): Get the viewer, launch it, log in and go to the place you want in SL. Disable ”Advanced” -> ”Caches” -> ”Threaded object cache reads” (this way the viewer will behave like LL's and other TPVs and the threads delay won't risk polluting the messages sequence). Enable ”Advanced” -> ”Consoles” -> ”Precise timestamps in log file”. Use the mini-map to help setting the draw distance so that you can see only the four sims in the FOV cone (192m did it for me at the approximate position of your screen shot). Log off. Relaunch the viewer, and at the login screen use ”Advanced” -> ”Debug tags”, and in the floater that opens, scroll down and check ”Messaging” in the list; you may also enable ”EventPoll” if you are interested in those in excess of what is already normally logged at INFO level. Close the floater. (*) Log in, wait for everything to rez and your avatar to bake, then log off. The CoolVLViewer.log will contain all the detailed login and rezzing sequences, with detailed log messages. (*) Note: this floater allows to enable/disable DEBUG level messages in real time; once logged in there is also an ”Advanced” -> ”Consoles” -> ”Allow DEBUG messages” option (automatically checked when you did enable a debug tag), to disable/re-enable at once all the debug messages corresponding to the configured tag(s) when you deem appropriate, so to avoid too much/irrelevant spam in the log file (and console).

Library versions are not the only problem... For example, a TPV I will not name by charity, decided that it was a good idea to rely on a systemd-specific library, meaning you cannot use that viewer at all on systemd-free Linux distros... Other issues could arise from the usage of specific toolkits (e.g. a specific GTK or QT version, or xdg-desktop-portal for the file selector), here again, complicating things if you do not have the corresponding toolkit installed on your system... For the Cool VL Viewer, I have been extra careful to avoid such silly dependencies, making it compatible with all (not too old) distros.