I agree!
I'll make the modification in the next days and give you a heads-up :-)

Thanks,

I tested a delayed cstv setup using tv_delay 7.

tv_status and manual inspection of the *.cfg files confirm that everything is configured correctly. Thanks for your work on this, @ppaulis. When connecting to the master cstv (no intermediate relay/proxy) on port 27020, the game-client disconnects after roughly 30–100 seconds with the reason NETWORK_DISCONNECT_BADDELTATICK.

I'm not sure if this is the right place to bring it up, but do you have any idea what might be causing this or whether it is related to the current changes? I honestly don't think it is. If necessary, I can create a separate issue. I would appreciate any guidance.

Logs from the game (Workshop Console):

[#2968270094 UDP steamid:[email protected]:27020 'server'] closed by peer (2027): NETWORK_DISCONNECT_BADDELTATICK
Steam Net connection #2968270094 UDP steamid:[email protected]:27020 'server' closed by peer, reason 2027: NETWORK_DISCONNECT_BADDELTATICK
Netchan 'server' closed unexpectedly: NETWORK_DISCONNECT_BADDELTATICK
Closing Steam Net Connection on socket 'client' to 10.10.10.15:27020, handle #2968270094 (0 (null))
CloseSteamNetConnection handle #2968270094 (userdata 0)
Disassociating NetChan server @ 10.10.10.15:27020 (10.10.10.15:27020) from Steam Net Connection handle #2968270094 (userdata 0)
Removing Steam Net Connection for 10.10.10.15:27020, handle #2968270094
Disconnection during connection phase. Sign-on state: 6 (SIGNONSTATE_FULL). Disconnect reason: 27 (NETWORK_DISCONNECT_BADDELTATICK).
Disconnected from server: NETWORK_DISCONNECT_BADDELTATICK
ClientModeCSNormal::OnEvent OnEngineDisconnectReason {
reason int( 27 = 0x1B )
}

the game-client disconnects after roughly 30–100 seconds with the reason NETWORK_DISCONNECT_BADDELTATICK.

I identified the root cause of the issue, and it is not related to the container setup, the compose configuration, or the CSTV implementation included here.

In short, the disconnects were caused by the newly added delta-tick enforcement and not by anything in this PR.

Valve introduced a new server command on 27 November 2024:

sv_deltaticks_enforce

With its default value (2), the server will kick all clients if their delta-tick acknowledgements are not received strictly in order. In my case, this caused CSTV to disconnect after roughly 30–100 seconds with:

NETWORK_DISCONNECT_BADDELTATICK

Setting the value to:

sv_deltaticks_enforce 0

immediately resolves the issue. With enforcement disabled, the client stays connected to CSTV without any disconnects.
Tested with tv_delay 7 and a direct connection to the CSTV master (no proxy).

I’ll open an issue to document this behavior so others who encounter the same problem can resolve it quickly.

Edit: Opened an issue and resolved it #194