CS2 GOTV and demos: recording and storage

GOTV on a Counter-Strike 2 server does two jobs: it relays a delayed live feed that spectators can connect to, and it records demos of what happened. Turn it on with tv_enable 1 in server.cfg, give it its own UDP port with tv_port, set tv_delay to the number of seconds spectators should lag behind the game, and add tv_autorecord 1 if you want a .dem file for every match without thinking about it. The change applies on the next map load, not instantly. Demos are written into game/csgo/ and a full competitive map is typically 100-300 MB, so the part people forget is not recording - it is deleting. This guide covers the cvars, recording by hand and automatically, watching, and how to stop demos filling the disk.

What GOTV actually is#

GOTV is a special spectator client that runs inside the server process. It joins as a bot named after tv_name, sees everything a spectator with full information would see, buffers it for tv_delay seconds, and then does two things with that stream: sends it to anyone connected to the GOTV port, and, if recording, writes it to disk.

That design explains most of its behaviour:

• It starts with a map. GOTV is created when a map loads. Setting tv_enable 1 mid-map does nothing until the next map change or restart.
• It is delayed for everyone. Spectators and the recorder both see the buffered stream. A demo is not delayed relative to the game in any way that matters for review, but a live viewer sees events tv_delay seconds late.
• It costs the server something. Packaging a full snapshot for GOTV every tick and buffering it is real work. On a 10-slot server it is small; on a busy community server with spectators connected it is noticeable.
• It may take a slot. The GOTV bot appears in the player list. On most builds it counts against the server's player limit, so a 10-player match server with GOTV is started with room for one more.

GOTV is not a replacement for anti-cheat, but a demo is the only reliable evidence a community server has. A CS2 competitive match server shows GOTV in the context of a full match setup; this post goes deeper into GOTV itself.

The tv_ cvars that matter#

These belong in game/csgo/cfg/server.cfg. Unlike mp_ round cvars, the game mode configs do not reset them, so server.cfg is the right home. CS2 server commands and cvars explains which file wins for which settings.

A working block for a match server:

tv_enable 1tv_port 27020tv_delay 90tv_delaymapchange 1tv_autorecord 1tv_maxclients 10tv_name "Longship GOTV"tv_title "Longship scrims"tv_password "spectate-only-7731"tv_relaypassword "relay-only-1902"

Defaults have changed between CS:GO and CS2 and between CS2 builds, so if you want to know what a cvar is set to on your server, type its name into the console without a value; it prints the current value and the default.

Choosing the delay#

tv_delay is the setting that gets set wrong in both directions.

The delay has a side effect at map end. With a 90-second delay, the last round has not been broadcast when the map ends. Without tv_delaymapchange 1 the map changes immediately, the GOTV stream is cut, and the demo loses the final round. With it on, the server waits for the broadcast to catch up before changing map - which means players see the scoreboard longer than they expect. That is the correct trade.

A large delay also costs memory: the server buffers the whole delay window. At 90 seconds on a 10-player server this is modest; at several minutes with a full server it is worth watching on the memory graph.

Ports and connecting to GOTV#

GOTV listens on its own UDP port. Spectators connect to it exactly like a server:

connect 203.0.113.10:27020password spectate-only-7731

Set the password before connecting with password <value> in the client console, or the connection is rejected. Spectators land in a free camera with the delayed stream and cannot interact with the game.

On a panel host the port numbers are whatever the server was allocated, not necessarily 27015 and 27020. Check the Network tab for the second allocation and set tv_port to that exact number; a tv_port the server was not given is a GOTV nobody can reach. On RE:NODE every CS2 plan has two port allocations for exactly this reason - the game and GOTV each get one. Game server ports explained covers what an allocation is and how to test one from outside.

Recording demos automatically and by hand#

tv_autorecord 1 starts a recording when a match goes live and stops it when the map ends. The file name includes the date, time and map, so demos sort chronologically in the folder. For a scrim or match server this is the right setting: every match is recorded, and nobody has to remember.

Manual recording is three commands:

tv_record scrim_2026-10-07_miragetv_stoprecordtv_status

tv_record <name> starts a demo with that name (.dem is added), tv_stoprecord finishes it, and tv_status prints whether GOTV is active, how many spectators are connected and whether a recording is running. If tv_record complains that GOTV is not active, tv_enable was set after the map loaded - change map and try again.

Match plugins usually take this over. MatchZy, the common match plugin on CounterStrikeSharp, records a demo per map when the match goes live and can upload it to an HTTP endpoint when the map ends, with its own settings for the demo folder and file name format. If you run a match plugin, let it own recording and leave tv_autorecord off, or you can end up with two recordings of the same map. The plugin's README lists the exact setting names for the version you install.

What a demo contains, and what it does not

A GOTV demo contains everything the server sent to GOTV: player positions, view angles, weapons, grenades, chat and the scoreboard. It is a server-side recording, so it shows where players really were rather than what one client saw. That makes it good for reviewing suspected cheating and for tactical review.

It does not contain voice by default, and it is not a video. To share a clip, someone plays the demo in the client and records the screen.

Watching demos#

Copy the .dem file into the client's game/csgo folder, then in the console:

playdemo scrim_2026-10-07_miragedemouidemo_timescale 2demo_gototick 64000

playdemo loads it (no extension needed), demoui opens the playback controls, demo_timescale changes speed, and demo_gototick jumps to a tick - at 64 tick, one minute is 3,840 ticks. Demos recorded on one CS2 version usually play on the next, but large updates have broken playback of older demos before. If a demo matters - a ban appeal, a tournament dispute - review it promptly rather than six months later.

Using demos to settle a cheating report#

The most valuable thing a demo does on a community server is turn "he is obviously cheating" into something you can look at. A routine that keeps it fair:

1. Note the time, map and suspect's name when the report comes in. With tv_autorecord on, that identifies the demo file.
2. Download the demo once the map has ended, never while it is still being written.
3. Watch the suspect in first person at normal speed for several rounds, then at half speed around the suspicious moments. Look at where the crosshair sits before an enemy is visible, not at the kill itself.
4. Switch to a free camera and watch what the suspect could actually see. A pre-aim through a wall is only suspicious if there was no sound, no teammate call and no common angle to explain it.
5. Ask a second admin to watch it without telling them your conclusion.

Write down the tick numbers for the moments that matter, so the next reviewer can jump straight there with demo_gototick. Ban appeals become a short conversation when the reply is "watch tick 41,200 and tell me what you see". Keep the demo as long as the ban stands. Server-side demos are much harder to argue with than a player's own client recording, which is the whole reason to run GOTV on a server that does not care about spectators. Server rules, moderation and staff covers the human side of handling reports.

Casting, tournaments and larger audiences#

A single GOTV accepts up to tv_maxclients spectators, and every one of them is served by the game server itself. For a scrim with two casters and a coach, that is fine. For an audience of hundreds it is not, because spectator traffic competes with the match for the server's CPU and network.

Two mechanisms exist for scaling out. Relays are additional GOTV instances that connect to the master GOTV - authenticated with tv_relaypassword - and re-serve the stream to their own spectators, so the game server only feeds one relay rather than a crowd. And GOTV can broadcast over HTTP with the tv_broadcast family of cvars, which is how large tournament broadcasts deliver the in-game spectator feed through ordinary web infrastructure. Both have changed between CS:GO and CS2 and are aimed at organisers with their own infrastructure; if you are running a league, read Valve's current documentation for them rather than any blog post, this one included.

For a community tournament, the practical answer is simpler: one GOTV with a 90-second delay and a password shared with the casters, plus a streamer showing the cast on a video platform. Viewers watch the stream, not the server, and the match server only feeds a handful of spectators.

Storage: size, retention and cleanup#

Demos are written next to the game files in game/csgo/ unless a plugin puts them elsewhere. They are not compressed on disk.

That last row is the trap. On a public server running all day, tv_autorecord 1 records every map, and the disk fills in days. Either turn it off on public servers and record by hand when there is a reason, or have a strict cleanup routine.

A cleanup routine that works on any host:

1. Decide a retention period - two to four weeks is plenty for a community server.
2. Download the demos you want to keep before that window closes; match demos worth keeping belong on storage you control, not on the game server.
3. Delete the rest. With the file manager, sort by date and remove in bulk; over SFTP, a script on your own machine can list and delete files older than the window.
4. Check free disk after each update day. CS2 updates are large, and a disk nearly full of demos is the most common reason an update fails halfway.

On RE:NODE the file manager and SFTP both work for this, and the Schedules tab can run console commands, backups and power actions on a cron expression - useful for a restart, but it does not run shell commands, so file deletion stays manual or goes through a plugin that uploads and removes demos. Backups of a CS2 server should not include gigabytes of old demos either; clear them before a manual backup so the slot holds the configuration and plugins you actually need. SFTP and the file manager has the connection details.

Troubleshooting#

No demo was recorded. tv_enable was set after the map loaded, so GOTV never started. Put it in server.cfg, change map, and check tv_status.

The demo is missing the last round. tv_delaymapchange is off and the delay is above zero, so the map changed before the broadcast caught up. Turn it on.

Spectators cannot connect to GOTV. tv_port does not match the port the server was allocated, the port is not open, or a password is set and the spectator did not enter it. Check the Network tab and the console line GOTV prints at map load.

The server is full one player early. The GOTV bot is taking a slot. Raise -maxplayers by one.

A demo will not play. It was recorded on an older CS2 version, or it was copied while still being written. Wait for the map to end before downloading, and review important demos soon after.

The disk is full and the server will not update. Old demos. Delete them, then run the update again. What to do when your game server keeps restarting covers what a failed update loop looks like from the outside.

FAQ#

Where are CS2 GOTV demos saved?

In game/csgo/ inside the server install, named with the date, time and map when tv_autorecord is on, or the name you gave tv_record. Match plugins can write them to another folder; check the plugin's demo path setting.

Does GOTV make the server laggier?

A little. GOTV packages a snapshot every tick and buffers the delay window, which costs some CPU and memory. On a 10-player match server it is not noticeable; on a busy public server with many spectators it can be, and tv_maxclients caps that part.

Should tv_delay be 0 or 90?

0 if nobody watches live and you only want demos. 90 or more if anyone can spectate during a match, because a zero-delay spectator can pass positions to a team.

Can I record a demo without GOTV?

Not server-side. Players can record their own client-side demo with record <name> in their console, but that only shows their view and network state. For a fair record of a match, GOTV is the tool.

How long should I keep demos?

Long enough to settle disputes - two to four weeks for a community server. Keep tournament and ban-related demos indefinitely, but on storage you control rather than on the game server.