Build 1622 STILL cannot continuously connect to any HiFi domain


#1

So, some time back I talked about how HiFi cannot maintain a connection to any server. I talked about how it connected to 5 servers, slowly trickled them down to 0, disconnecting, then re-connected.

I keep downloading the occasional build of HiFi, on the hope that you guys have fixed this issue, however I am repeatedly disappointed.

The newer versions of HiFi have a different style of logs, however. So maybe this time you can identify exactly what my problem is. Is it on my end, or is it a problem in HiFi itself?

I have tried visiting numerous domains in build 1622, and still, the servers go to 5, then 3, then 0, before reconnecting. Nothing appears, except rarely, and those things blink out of existence soon after appearing.
This makes HiFi basically unusable.

This is a log I have from the Ai Austin’s domain:

[DEBUG] [12/14 22:45:51] Clearing domain octree details...
[DEBUG] [12/14 22:45:52] Sending connect request to domain-server at "hifi.aiai.ed.ac.uk"
[DEBUG] [12/14 22:45:52] Including username signature in domain connect request.
[DEBUG] [12/14 22:45:52] Domain ID changed to "be361aa0-abb9-4df0-b41f-236c585cc1ac"
[DEBUG] [12/14 22:45:52] NodeList UUID changed from "00000000-0000-0000-0000-000000000000" to "79f3596b-a914-4ac8-bc2f-f465de88ba06"
[DEBUG] [12/14 22:45:52] Added "Avatar Mixer" (W) {ba6fb7d9-4ffd-4470-8078-53a7af733fdb} 129.215.219.138:58773 / 129.215.219.138:58773
[DEBUG] [12/14 22:45:52] Added "Voxel Server" (V) {5aca0c73-f70c-4453-8f30-31139b751d58} 129.215.219.138:58770 / 129.215.219.138:58770
[DEBUG] [12/14 22:45:52] Added "Metavoxel Server" (m) {8939068c-483c-4026-b524-2beb1e771425} 129.215.219.138:58774 / 129.215.219.138:58774
[DEBUG] [12/14 22:45:52] Added "Entity Server" (o) {624c1742-fdf7-4dd1-8b86-1fb5d134f33c} 129.215.219.138:58771 / 129.215.219.138:58771
[DEBUG] [12/14 22:45:52] Added "Audio Mixer" (M) {c7a74bab-cf17-4d8f-b6d5-92be9eb789ce} 129.215.219.138:58772 / 129.215.219.138:58772
[DEBUG] [12/14 22:45:52] Voxel costs are 0 per voxel and 0 per meter cubed
[DEBUG] [12/14 22:45:52] Destination wallet UUID for voxel payments is QUuid("{00000000-0000-0000-0000-000000000000}")
[DEBUG] [12/14 22:45:52] VoxelSystem... voxel server {5aca0c73-f70c-4453-8f30-31139b751d58} added...
[DEBUG] [12/14 22:45:53] Activating local socket for network peer with ID "5aca0c73-f70c-4453-8f30-31139b751d58"
[DEBUG] [12/14 22:45:53] Activating local socket for network peer with ID "8939068c-483c-4026-b524-2beb1e771425"
[DEBUG] [12/14 22:45:53] Activating local socket for network peer with ID "ba6fb7d9-4ffd-4470-8078-53a7af733fdb"
[DEBUG] [12/14 22:45:53] Activating local socket for network peer with ID "624c1742-fdf7-4dd1-8b86-1fb5d134f33c"
[DEBUG] [12/14 22:45:53] New public socket received from STUN server is 86.162.168.163:54044
[DEBUG] [12/14 22:45:53] Activating local socket for network peer with ID "c7a74bab-cf17-4d8f-b6d5-92be9eb789ce"
[DEBUG] [12/14 22:45:53] Adding avatar with sessionUUID QUuid("{e96945df-aea7-4aea-89f4-4bfd4ce21a52}") to AvatarHashMap.
[DEBUG] [12/14 22:45:54] Removing Avatar with UUID QUuid("{e96945df-aea7-4aea-89f4-4bfd4ce21a52}") from AvatarHashMap.
[DEBUG] [12/14 22:45:58] Killed "Voxel Server" (V) {5aca0c73-f70c-4453-8f30-31139b751d58} 129.215.219.138:58770 / 129.215.219.138:58770
[DEBUG] [12/14 22:45:58] Killed "Entity Server" (o) {624c1742-fdf7-4dd1-8b86-1fb5d134f33c} 129.215.219.138:58771 / 129.215.219.138:58771
[DEBUG] [12/14 22:45:58] VoxelSystem... voxel server {5aca0c73-f70c-4453-8f30-31139b751d58} removed...
[DEBUG] [12/14 22:46:00] Packet of type 3 received from unknown node with UUID 5aca0c73-f70c-4453-8f30-31139b751d58
[DEBUG] [12/14 22:46:02] Clearing the NodeList. Deleting all nodes in list.
[DEBUG] [12/14 22:46:02] Killed "Metavoxel Server" (m) {8939068c-483c-4026-b524-2beb1e771425} 129.215.219.138:58774 / 129.215.219.138:58774
[DEBUG] [12/14 22:46:02] Killed "Avatar Mixer" (W) {ba6fb7d9-4ffd-4470-8078-53a7af733fdb} 129.215.219.138:58773 / 129.215.219.138:58773
[DEBUG] [12/14 22:46:02] Killed "Audio Mixer" (M) {c7a74bab-cf17-4d8f-b6d5-92be9eb789ce} 129.215.219.138:58772 / 129.215.219.138:58772
[DEBUG] [12/14 22:46:02] NodeList UUID changed from "79f3596b-a914-4ac8-bc2f-f465de88ba06" to "00000000-0000-0000-0000-000000000000"
[DEBUG] [12/14 22:46:02] Resetting current domain connection information.
[DEBUG] [12/14 22:46:02] Clearing the NodeList. Deleting all nodes in list.
[DEBUG] [12/14 22:46:02] Clearing domain octree details...

It basically loops between the ‘clearing domain octree details’ thing. It seemingly connects, then gets (possibly, if not earlier) to “Packet of type 3 received from unknown node with UUID…” before disconnecting. However, I may be wrong about that, as it starts ‘killing’ things before it reaches that line.

After re-installing, it keeps disconnecting after a red flash.

Oh and the mic line is broken now, both before and after reinstalling.


#2

I’ve been tracing an issue similar, but nowhere near as severe as yours.

May I ask what OS you’re running, are you connecting to your network via direct cable ethernet or WiFi? Also when running Interface, do you have the statistics display open (if not press % to display) and make note of your 3 values of ping time displays.


#3

I’m out right now, so I cannot get the latter ping details, but I’m running Windows 8.1, with a WiFi connection.


#4

Oops, sorry.

Anyway, the three pings! They all seemed to hover around 370/440ish values, sometimes going higher or lower, before blinking out (–) completely.


#5

Those are pretty high ping times and may be indicating some packet loss or other network issue leading to inability to stay connected. As an example, I typically see around 120ms to a domain in Europe from East Coast USA, 80-90 from East USA to West USA.

One thing I found with my wireless network setup was that it was performing very poorly with UDP packets - I had switched back to a hard cable connection and all was fine. Then I noticed my router had a firmware update, applied it and it works fine now. With that in mind, if you can do a hard wire connection that might be worth a try to see if any improvement.


#6

That log looks very similar to mine every time I’ve tried to connect to a domain other than my localhost. Connect to assignment clients, then drop. Repeat. It’s been like this since I started (build 850 or so).
I’ve tried multiple ISPs and a VPN in three different countries - see https://alphas.highfidelity.io/t/unable-to-connect-to-remote-servers/703).

Dropping out continuously makes following what’s going on at alpha meetups very difficult!

  • davedub

#7

BUMP
Looking for some answers here.
I thought it was just because I was running a domain from a pitiful Australian home connection (7 down and 0.5 up) that this was happening on my domain.
Now I am running a hosted system on an industrial strength backbone, located in San Francisco, and still approx every 15 - 20 seconds everything goes red and disappears momentarily (5 seconds) then it all comes back.

According to what I just learned every time this happens the interface calls for all the objects from the servers to be reloaded again, if this is true then its an incredible waste of resources not to mention capping out my data transfer limits prematurely.

I once believed this to be when assignment clients dropped in and out but this is seemingly not the case. Assignment clients arent active so what gives?
Why would everything dropout like this? its hard to work when 25% of the time I sit waiting to reconnect.
Is this the fault of my interface trying to work with a weak net connection? if so why does it not happen on Sandbox?
Does anyone have any advice or answers for this please?


#8

As of Build 1724, this issue is still present, but now it’s even more glaring as it crashes Interface occasionally. So far I’ve had it crash twice when dropping connection.
But it doesn’t always happen, so I am unsure if it is connected.
I feel as if my ping shouldn’t be as high as it is.