Advanced settings reference
Every tuning knob in the server, what it actually changes, what it costs, and which symptom it fixes.
On this page
Settings → Advanced, behind a warning banner.
Two things to know before you touch anything:
- Every default is exactly what the server does anyway. Opening this section and changing nothing changes nothing. There is no hidden “make it good” setting you are missing out on.
- Every field shows where its value came from (default, an environment variable, or something you set) and has a Reset that puts it back.
Most fields apply to new playback sessions, so a stream already running finishes on the old value. The few that need a restart say so on the field itself.
Everywhere below, 0 or blank means automatic.
Transcoding
What happens when a device cannot play a file as it is and the server has to re-encode it live.
| Setting | Default | Range | What it does |
|---|---|---|---|
| Encoder quality | Balanced | Speed, Balanced, Quality | The preset handed to the encoder. Speed uses less processor for a slightly worse picture at the same bitrate; Quality is the reverse. On a machine with a hardware encoder this costs less than you would think |
| Encoder pacing | 4 | 1 to 16, 0 unlimited | How much faster than real time the server is allowed to encode. Encoding at 4x means it stays comfortably ahead of a viewer without burning the processor building an hour of buffer nobody will watch. Raise it if seeking feels sluggish; lower it on a machine doing other work |
| Initial burst | 20 s | 5 to 300 | How many seconds it encodes at full speed before pacing kicks in. This is what makes playback start instantly. Raise it if playback starts but stutters in the first few seconds |
| Segment duration | 4 s | 2 to 10 | How the stream is chopped up. Shorter starts faster and seeks more precisely; longer is more efficient and steadier over a poor connection |
| Threads per transcode | Auto | 0 to 64 | Processor threads for one software encode. Auto uses what is available. Set it to leave headroom for something else on the machine |
| Process priority | Normal | Normal, Below normal, Low | How the operating system schedules the encoder. On a machine you also use for something else, set this to Below normal. Encoding then gets out of the way instead of making everything else sticky |
| Max simultaneous transcodes | Unlimited | 0 to 20 | A hard ceiling on live re-encodes. At the limit, a new one is refused with a message saying the server is busy rather than being queued behind a spinner or silently degraded. Files that play directly, and files that only need a container swap, always start regardless: they cost almost nothing |
| Hardware decode | On | On, off | Whether the graphics chip decodes as well as encodes. Leave it on. Turn it off if a specific file glitches or fails, which usually means a driver bug |
| Encoder backend | Auto | Auto, NVENC, QuickSync, AMF, VAAPI, VideoToolbox, Software | Auto probes what the machine has with a real test encode and picks the best. Force one only when you are diagnosing something. If a forced backend does not actually work, the server falls back to software and says so on the About page. Needs a restart |
| HDR output | Preserve | Preserve, Tone map | Preserve sends HDR untouched to devices that can take it, and maps it down only for devices that cannot. Tone map maps it down always, which is the answer when your HDR TV is producing a washed-out picture |
| Tone-map algorithm | Hable | Hable, Reinhard, Mobius, Clip, Linear, Gamma | How HDR is squeezed into a normal range when it has to be. Hable protects highlights; Reinhard is flatter; the others exist because taste varies |
| Scratch folder | Data directory | Any writable folder | Where in-progress transcode segments are written. Point it at a fast disk, or at a RAM disk if you have memory to spare. Never a network share. Needs a restart |
| Idle stream timeout | 3 min | 1 to 60 | How long a stream nobody is fetching is kept before its encoder is stopped. This is what reclaims a session when somebody pauses and wanders off |
| Downmix volume boost | 1.0 (none) | 1.0 to 3.0 | When surround is folded down to stereo, dialogue can end up quiet against the effects. This is the fix for “I cannot hear what they are saying on my phone”. Try 1.5 to 2.0. We ship 1.0 so that updating never changes how loud anything is for anyone |
Worth knowing. Most playback never touches any of this. The server plays a file as it is whenever the device can take it, only swaps the container when that is enough, and re-encodes as a last resort.
Remote streams
Applies only to people watching from outside your network. Anything on your own network is never capped, never counted, and never touched by these.
| Setting | Default | Range | What it does |
|---|---|---|---|
| Maximum resolution | No cap | 480p, 720p, 1080p, 2160p | Ceiling for remote viewers. Useful when your upload cannot sustain 4K to three houses |
| Maximum bitrate | No cap | Up to 100000 kbps | Ceiling on the data rate. Compared against the file’s average bitrate, which is size divided by duration |
| Trusted proxies | Blank | A list of CIDR ranges | If your server sits behind a reverse proxy, list it here so the real visitor address is read from the forwarded headers instead of the proxy’s own |
| Extra local subnets | Blank | A list of CIDR ranges | Networks that should count as local for the purpose of streaming |
The two caps are independent, which is worth pointing out because most products couple them: you can cap the bitrate without forcing the resolution down, so a 4K stream simply gets less generous rather than becoming 1080p.
When a cap is what is limiting a stream, it is named as the reason in the diagnostics overlay in the player, so you can see why something looks softer than you expected.
Extra local subnets, and what it does not do
If your server is on a VLAN, or in Docker with its own bridge network, or reachable over a VPN, traffic from your own house can arrive looking remote. It then gets capped and counted as remote, which is wrong and is one of the most common complaints in this category.
Listing those ranges here fixes exactly that: they are classified as local for streaming, so they are never capped and never count against your five remote streams.
Careful, and deliberately so. This grants nothing else. Adding a range here does not make anyone on it trusted, does not skip sign-in, and does not give anyone the ability to manage your server. A setting that does all of that exists in other products and it is a foot-gun. Ours does not.
Library and background work
| Setting | Default | Range | What it does |
|---|---|---|---|
| Generate preview thumbnails | On | On, off | The strip of images you see when you scrub the timeline. Turning it off stops making new ones. Existing previews are kept, because they represent hours of work |
| Preview frame interval | 3 s | 1 to 30 | How often a preview frame is captured. Smaller is smoother scrubbing and more disk. Applies to previews generated from now on; nothing already made is thrown away |
| Preview frame width | 240 px | 120 to 480 | How big each preview frame is. Same rule: new ones only |
| Scan at low priority | Off | On, off | Runs the scanner’s file inspection at idle priority. Turn it on if a scan makes the machine unresponsive |
Two related settings live in Libraries rather than here, because they are about your library rather than about performance: how often the server rescans, and how many files it inspects at once.
Live TV and recording
| Setting | Default | Range | What it does |
|---|---|---|---|
| Timeshift buffer | 120 min | 10 to 1440 | How far back you can rewind live TV. This is disk, per active channel |
| Default recording pre-padding | 0 min | 0 to 10 | Start every recording this many minutes early, when you have not chosen a padding yourself |
| Default recording post-padding | 0 min | 0 to 120 | Run every recording this many minutes late. Set this if you record sport |
| Guide refresh | 6 h | 1 to 48 | How often guide data is pulled |
| Playlist refresh | 12 h | 1 to 168 | How often the channel list is pulled |
| Live stream grace period | 45 s | 15 to 600 | How long a live connection is held open after you stop watching. Longer makes flicking between channels instant; shorter is politer to a provider that counts connections |
Padding you choose on an individual recording always wins over the defaults, including when you deliberately choose zero.
Server and data
| Setting | Default | Range | What it does |
|---|---|---|---|
| Database cache | Auto | 0 to 1024 MB | Memory the database is allowed for caching. Auto is right for almost everyone. A very large library on a machine with plenty of memory may benefit from more |
| Nightly backups kept | 7 | 2 to 30 | How many nightly snapshots to keep |
| Weekly backups kept | 4 | 0 to 12 | How many weekly snapshots to keep |
| Keep transcoder logs | Off | On, off | Writes the full encoder log for each session to disk instead of keeping a short tail in memory. Turn it on when you are reporting a playback problem, then turn it off. The newest fifty are kept |
Move data directory
Moves your database, artwork, and thumbnails to another drive. Not your media, which is untouched.
Available on Windows installs. It checks the target is empty, writable, not inside the current one, and has room, then stages the move for the next restart. The old folder is copied rather than moved and is left exactly where it was, so you can prove the new location works before anything is thrown away. A separate button removes the old data when you are ready, and tells you how much space that frees.
If the copy fails for any reason, the server boots from the old folder as though nothing happened and tries again next time.
On Linux and Docker, do it by hand: stop the service, move the folder, update the service file or your compose volume, start it again.
Things that are deliberately not here
Stated so you stop looking for them:
- A file chunk size for direct play. This is not a real server setting. When a device plays a file directly it is asking for byte ranges over HTTP and the device decides how much to ask for. The knob some products are rumoured to have does not exist in them either. The real levers for network behaviour are segment duration and encoder pacing, both above.
- A hard processor percentage cap. Nobody in this category ships one, because the mechanisms for it are per-platform and unpleasant. Threads and priority are the honest levers and they are above.
- A total upload bandwidth budget. Per-stream caps are here; an aggregate ceiling is not, yet.
- Quality by constant rate factor. Our streaming ladder is bitrate-driven by design, so an encoder quality target would not do what you expect.
- Deleting segments mid-session. It saves a little disk and breaks instant seeking backwards.
- Trusting a subnet for authentication. See the note above. Not an oversight.
Something here wrong or missing? Tell us at support@kammcs.com and we will fix it.