Cap libvpx threads so the encoder doesn't starve a colocated TS6 server

[queueeee]

Symptom

On the upgraded host (6 vCPU, 8 GB) at 1080p the broadcaster's memory plateau looks great (~280 MB stable), but the operator reports:

[Beim Join] sehe keinen Log, weil der Server vorher stirbt bzw das unterliegende software [reset]

The bot is alive, the TS6 server is alive, until the moment a viewer clicks Join — at which point everything goes silent. No respondjoinstreamrequest ever leaves the bot. No log lines around the join.

Diagnosis

This isn't memory anymore — that's fixed by #22. It's CPU starvation.

Our broadcaster's _auto_thread_count was a straight port of aiortc.codecs.vpx.number_of_threads, which returns min(cpu_count, 8). On the 6-vCPU host, 1080p set thread_count = 6. So during each frame's encode, libvpx pinned all six cores at once. Inter-frame gaps (a few ms at 30 fps) were the only window for ffmpeg's reader thread, the asyncio event loop, and the TS6 server's watchdog to make progress.

When the WebRTC handshake's added load tipped that balance, the TS6 server's watchdog couldn't get scheduled in time, decided the process was hung, and killed it. The bot's TS3 socket then disconnected — losing whatever log lines were buffered locally and the in-flight join response.

ts6-manager doesn't hit this because Pion encodes much faster (less wall-time pinned per frame) and because they run encode in a separate Go process.

Fix

_auto_thread_count now caps at min(aiortc_pick, cpu_count - 2, 4):

Host	Resolution	Old (aiortc)	New
2 vCPU	1080p	2	1 (leaves 1 free)
6 vCPU	1080p	6	4 (leaves 2 free)
8 vCPU	1080p	8	4
6 vCPU	720p	4	4

Operators with measured headroom can override via:

ENCODER_THREAD_COUNT=6

And operators whose host can't sustain real-time at the configured resolution can speed the encoder up (at the cost of quality):

ENCODER_CPU_USED=-10

Test plan

• pytest — 253 passed (1 new test pinning the heuristic across 2/6/8-vCPU and 720p/1080p combinations).
• mypy --strict clean.
• ruff check clean.
• Live: at 1080p30 with the new cap, the TS6 server should no longer get watchdog-killed mid-join. RSS plateau still ~280 MB. respondjoinstreamrequest actually arrives at the viewer.

Operator notes

cd /opt/ts6-stream-bot
git pull
docker compose -f docker-compose.yml -f docker-compose.host.yml down
docker compose -f docker-compose.yml -f docker-compose.host.yml up -d --build
docker compose -f docker-compose.yml -f docker-compose.host.yml logs -f

You don't need to change .env — the new defaults pick the safe values automatically. If 1080p30 still looks rough (bot logs stale_frames_dropped in the thousands when you down the stack), drop the encoder speed:

ENCODER_CPU_USED=-10

Or fall back to 720p30:

SCREEN_WIDTH=1280
SCREEN_HEIGHT=720

https://claude.ai/code/session_016DuCjRJK995Tj9aDhhB9at

---

Generated by Claude Code