Connection appears successful, then channel commands time out and session drops around 60 seconds

[computertech1012]

Connection appears successful, then channel commands time out and session drops around 60 seconds

I'm reporting this on behalf of friends using ttaccessible on an M2 MacBook Air. I don't have a Mac to reproduce it locally, but I administer the TeamTalk server and checked its logs. The affected user can provide the exact ttaccessible and macOS versions and client diagnostics as a follow-up.

What they see

The user connects and appears in the root channel. Attempts to join another channel do not complete. The app reports: “The server did not respond within the expected time.” Around one minute after login, the server records the session disconnecting. Restarting the client did not resolve it. The problem started before the user updated the app; I do not want to assume the update caused it.

Server-side observations

• Three recent connections authenticated and joined root normally. Each disconnected about a minute after login. There is no logged kick.
• On two of those connections, the server recorded 34 and 36 subscription changes immediately after login, including users outside the current channel. I understand that ttaccessible applies default subscriptions to every visible user and may send an unsubscribe and a subscribe for each user.
• No firewall block or command flood denial appeared in the logs. Another client using the same account from the same public IP stayed connected and could join a channel.
• The server did not restart, and other users remained connected.

These observations do not prove the client is at fault. A server response or client event-processing stall could still explain the timeout. I have omitted the server address, public IP, account name, and private channel names here; I can provide targeted diagnostics privately if they become necessary.

What I hope you can check

1. Which operation produces this particular connectionTimeout: initial connect/login or waitForCommandCompletionLocked for a later command? Could a diagnostic log include the pending command ID, operation, elapsed time, and whether a matching success/error event was seen, without recording private message content or credentials?
2. Can the post-login default subscription burst delay or crowd out a channel-join command or its completion event? Does applying defaults to users in other channels need to happen synchronously before normal navigation?
3. If a user logs in and gets server events but no command completion, can ttaccessible recover or give a more specific error before the connection drops?

I can run an isolated server-side subscription-burst test without a Mac. That would check how the server responds to the command sequence, but it would not exercise ttaccessible's macOS event loop. If you have a particular diagnostic or minimal test you want us to run, please tell me what would be most useful.

[math65]

Thanks for the detailed report and for checking the server side, it helped a lot.

What changed, in 1.13.0-beta.2 (out today):

• At login, the app used to send an unsubscribe and a subscribe for every user on the server, whatever the settings. That's the 34-36 changes you saw. It now only sends what differs from what the server already applies, which with default settings means none, like the Qt client.
• When a command gets no reply, the audio log now records which command it was, how long it waited, and the SDK's own view of the link: how long since the server was last heard on TCP and on UDP, and whether a late reply ever came.

To your three questions:

1. The timeout comes from the channel join, not the login. After sending it, the app waits 10 seconds for the server's reply.
2. The subscription burst could delay the join, but I haven't found a way for it to block it. So I can't promise the fix above solves this.
3. Not yet. The new log should at least tell us which side goes quiet.

One thing stands out. A drop about 60 seconds after login with no kick looks like the server's user timeout. From the server code, it only drops a user after hearing neither a TCP ping (the client sends one every 30 seconds) nor a UDP keepalive for that long. So after login, nothing from this client seems to reach the server anymore, including the join.

If you can check, it would help:

• whether the server log marks those disconnects as timeouts;
• whether the server received the join command at all;
• whether UDP is open on port 10335, not just TCP;
• whether the server uses encryption, which version it runs, and its user timeout;
• which client the working session used.

For your friends: in Preferences > General, tick "Include beta versions", then use Check for Updates. If it happens again, they shouldn't quit the app. They can go to Help > Contact the Developer, choose "Report a problem", and tick "Attach the audio diagnostic log". The log is erased at every launch, so it has to be sent from that session.