A connection cap and a stream buffer are different controls. Increasing either blindly can hide a failing source or consume resources without fixing playback. First determine whether the problem affects every listener, a single network path or only new connections.
Read each limit in its own unit
| Setting | Meaning | Common mistake |
|---|---|---|
limits/clients | Concurrent client connections, including web and admin requests | Treating it as a pure audience cap |
limits/sources | Allowed active sources, including active relays | Counting only encoders |
mount/max-listeners | Listener ceiling for one mount | Expecting it to raise the server limit |
queue-size | Stream queue size in bytes | Reading it as seconds |
burst-size | Bytes initially offered to a new listener | Setting it above the queue |
source-timeout | Allowed source silence in seconds | Using it to repair a broken connection |
header-timeout | Time allowed for the incoming request header | Confusing it with playback buffering |
The old threadpool example is historical, and client-timeout is described as unused in the documentation. Neither is a useful first tuning control for a current installation.
Use a small, explicit change
This excerpt replaces the corresponding values inside an existing <limits> block. It is an example to evaluate, not a sizing recommendation for every station:
<queue-size>524288</queue-size>
<burst-size>65536</burst-size>
<source-timeout>10</source-timeout>Keep the burst below the queue size. A player can still maintain its own buffer, so changing the server’s burst does not prescribe end-to-end latency. A larger queue lets a slow listener lag further behind and consumes memory; it does not increase that listener’s available network bandwidth.
Estimate, measure, compare
As a simplified calculation, 200 listeners receiving 128 kbit/s require 25.6 Mbit/s of media payload before protocol overhead. This is arithmetic, not a tested server capacity. Add relay traffic and other activity when planning the actual network.
Record listener counts, source continuity and slow-listener statistics before changing one value. Reproduce the failure with the same media and player. If all listeners stall together, check source delivery before increasing queues. If only one listener is removed, inspect its connection and elapsed lag. Retain the old configuration so a change can be reversed.