Teleports frequently failing, causing viewer timeout and disconnect.
tracked
Quinn Elara
Teleports between regions will sometimes (but fairly frequently) fail, causing the viewer to timeout and disconnect.
I will try and log when and where this happens, and update where possible. This is what I have so far:
User: Quinn Elara
7/12/2024 - 14:55 GMT / 06:55 PST, FROM REGION "TOKYO ZERO"
7/12/2024 - 15:25 GMT / 07:25 PST, FROM REGION "Vanilla Bae"
Format: dd/mm/yyyy
Log In
Activity Feed
Sort by
Quinn Elara
Just want to add that I'm seeing more frequent disconnections recently. Unsure of the cause.
Logan Elf
Monty Brandenberg Maestro Linden
I get these random TP disconnects. Sometimes can go for days/weeks without any then a slew of them close together. Just had a couple of TP disconnects at approx 9PM SLT and again around 9:24PM. Attached the log for the 2nd disconnect (9:24PM) going from
Amadoris
to Elf
. I'm using Firestorm Beta viewer 7.1.11.76751
Maestro Linden
tracked
Monty Brandenberg
Quinn Elara Just wanted to thank you for the excellent logging data. I know we don't make this easy to do. Very grateful for it.
Quinn Elara
Encountered a teleport fail.
12/12/2024 - 15:14 GMT / 07:14 PST, FROM REGION "Barcola", TO REGION "Sistiana", Logfile https://justpaste.it/hxfrp
Maestro Linden
Quinn Elara: Thanks for all of these incident reports and logs (including viewer and hippolyzer). My suspicion is that there's some UDP loss to your viewer, and that the 12/12/2024 13:52 GMT region-connecting incident has the same root cause as the crossing and TP failures you note. I think we have enough data to digest for now.
Quinn Elara
Ran into another fail upon region crossing.
12/12/2024 - 14:31 GMT / 06:31 PST, FROM REGION "Wiley Post" TO REGION "Grizwold", Logfile: https://justpaste.it/ez9wy
Quinn Elara
Just ran into a more elusive problem wherein the viewer fails to login, getting stuck on "Connecting to simulator".
12/12/2024 13:52 GMT / 05:52 PST, Region "May Queen"
Logfile: https://pastebin.com/SDTdR1aY
Quinn Elara
Just had another fail. This one failed upon region crossing, rather than a conventional teleport.
11/12/2024 - 22:28 GMT / 14:28 PST, FROM REGION "Whinlatter", TO REGION "Macclaine"
Maestro Linden
under review
Maestro Linden
needs info
Hi Quinn, thanks for the TP failures can come from a variety of sources, including an issue with the source or destination region or your connection itself.
Knowing the time and source region names for the teleport is helpful, but we need more info in order to investigate a particular TP failure properly. If this happens again, could you please update this ticket with the all of following info?
- Note the time of the failed teleport
- Note the name of the source region involved in the failed TP
- Note the name of the destination region involved in the failed TP
- Attach (or otherwise make available) a copy of your viewer's SecondLife.log file from the session with the failed TP. This page describes where to find the file: https://community.secondlife.com/knowledgebase/english/how-to-report-a-bug-r224/#Section__3
Quinn Elara
Maestro Linden Just had another TP fail.
10/12/2024 - 22:23 GMT / 14:23 PST, FROM REGION "May Queen" TO REGION "equal10", Logfile: https://pastebin.com/j41QnUds
Maestro Linden
Quinn Elara: Thanks for the details. I looked at your viewer log and the sim logs, and the story appears to be:
- Your viewer's TP attempt to equal10 failed immediately because the region was full at the time
- Despite this failure, your viewer apparently didn't get the failure message (or didn't handle it properly) and continued to display the TP progress screen.
- The May Queen simulator got your teleport cancelation request about 90 seconds after the TP failure, but didn't know anything about an active teleport (as the previous one had already failed)
- It looks like your viewer was fully connected to 'May Queen' when you began the logout process
My impression is that your viewer got into a funky state after failing to get or process the 'TeleportFailed' message, causing it to display the TP progress screen and then possibly not showing the proper view of your original region after you tried to exit it.
Right now I'm seeing TP failures from "May Queen" to "equal10" due to the latter being full. My viewer (Second Life Release 7.1.10.10800445603 ) seems to be handling the TP failure message properly though. With your Alchemy viewer, do you generally see 'region full' TP failures properly?
Quinn Elara
Maestro Linden Normally, yes - the "Region full" message does display when appropriate.
Maestro Linden
Quinn Elara: Okay, I think we need to dig further into this repro case. From the logs of the Dec 10 incident, the simulator thought it properly sent 'TeleportFailed' to the viewer, but the viewer either (1) ignored this message or (2) failed to receive it, causing the viewer to behave as though it were in TP limbo when in fact the agent was firmly grounded in "May Queen".
The best way to know if the issue is (1) or (2) is to look at the conversation between the viewer and simulator. One tool (which we often use internally) to look at stuff like this is Hippolyzer, which acts as a local proxy for the UDP and HTTP messages between the viewer and simulator: https://github.com/SaladDais/Hippolyzer
It's sort of like using Wireshark, but looking at higher-level messages specific to SL protocols.
Would you be comfortable using something like that to grab the viewer<>sim message log during a failed TP attempt? It makes things a bit slower when active, but runs pretty well on Linux (it runs OK on mac OS, and is a pain to get working on Windows).
Quinn Elara
Maestro Linden It happens I've used Hippolyzer before, although this time around I had trouble getting it running as the build system for it seems to be broken as of Python3.13 - I've managed to get around it by manually installing dependencies, so will run the viewer with Hippolyzer and see what happens when a TP fail occurs.
Maestro Linden
Quinn Elara: Good luck with the build at let us know what you see. I also noticed some issues building dependencies on a python3.13 system (Mac OS Sequoia). It looks like some of the dependencies have bug fixes (like this one for cffi https://github.com/python-cffi/cffi/issues/71 ). The easier solution I found was to use a python3.12 system for my venv.
Quinn Elara
Maestro Linden See my other comments on this issue, I have more failure samples with the viewer's logfile and hippolyzer log attached.
I did actually do the same, went back to python3.12 as although I got a build running with 3.13, the proxy didn't actually work so it was effectively useless. Work just fine with 3.12 though, which is where all the above logs came from.
Load More
→