Closed nickdnk closed 1 year ago
I've tried with tv_snapshotrate 32
, 64
and 128
and the behavior is the same, although the memory leak size and demo flush time seems to increase as the snapshot rate goes up. On 128 it was almost 2GB leaked and 4-5 second flush but on 32 it was only about 1GB and around 1-2 seconds flush, so while there is a correlation on severity, the problem occurs with any snapshot rate. I don't think there is any good argument for retaining functionality to turn this stop-delay off.
I do not like the
get5_demo_postpone_stop
option that I added. I think it's better to default to handling this gracefully instead of forcing users to "find out if it works or not".This way, we always wait with stopping the demo recording until GOTV has broadcast, an add another 10 seconds of grace-period if there is a
tv_delay
(which causes the bug; flushing to disk does not freeze GOTV with no delay). With no delay or GOTV enabled, the recording still stops 15 seconds after the match ends, like it did before.I have confirmed the freeze/memory leak bug also on my own server by playing a 10 minute game with 9 bots using:
tv_delay 120
tv_snapshotrate 128
This is the result when the demo is stopped:
During those 3.48 seconds, the server does not respond and presumably this is what also freezes GOTV. The memory consumption of the
srcds
process also goes up to around 2.5GB from around 700MB.sm_dump_handles
gives a total SourceMod consumption of around 200MB before and after this operation, so it's definitely a bug in the game and not Get5, which seems to have been there for a long time: https://forums.alliedmods.net/archive/index.php/t-262232.html. We likely can't do anything about this. The memory consumption doesn't come down again, not by changing the map or doingtv_stop
to entirely disable GOTV. It must be rebooted.Also got rid of a constant that was only used in one place.