open_notebook/services/systemd/open-notebook-stt.service

[Unit]
Description=Open Notebook STT (faster-whisper, OpenAI-compatible wrapper on :8902)
After=network.target

[Service]
Type=simple
WorkingDirectory=%h/open-notebook/services
ExecStart=%h/miniforge3/bin/python3 stt_server.py
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal
Environment="STT_HOST=0.0.0.0"
Environment="STT_PORT=8902"
# GPU 2 eindeutig per UUID, NICHT per Index — siehe Kommentar in
# open-notebook-tts.service.
Environment="CUDA_VISIBLE_DEVICES=GPU-83ba6d1f-ebbe-f8c8-1433-153e0ebc3866"
Environment="PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True"

[Install]
WantedBy=default.target
Fix two podcast failures: dead TTS server after reboot + CUDA OOM Podcast generation failed twice at the audio stage, for two unrelated reasons that look similar from the UI but need opposite fixes. 1) TTS/STT ran as nohup background processes and silently did not survive a reboot. Podcasts then failed with "Failed to generate speech: All connection attempts failed" (httpx.ConnectError) even though outline and transcript had generated fine. Both now run as systemd user units. The unit files are versioned in services/systemd/ (using %h, not a hardcoded home) and installed by scripts/start_services.sh, which also enables linger so they start on boot without a login session. They pin GPU 2 by UUID, not by index: CUDA orders devices "fastest first", so index 2 can resolve to the T600. 2) GPU 2 is shared by three processes (TTS, STT and the separate chatterbox-tts MCP service on :9999), leaving ~12 GB of headroom. podcast_creator sends TTS_BATCH_SIZE (default 5) clips concurrently, and since /audio/speech is a sync FastAPI handler, they generated genuinely in parallel on one shared model. Activation memory multiplied, the TTS process hit 16.7 GB and threw torch.OutOfMemoryError, surfacing as "HTTP 500" from the endpoint. tts_server.py now serializes generation behind a lock (GPU-bound work, so parallelism buys no throughput — it only multiplies peak VRAM) and frees the cache afterwards. TTS_BATCH_SIZE=1 keeps the client from queuing requests in that lock and running into esperanto's 300s TTS timeout; ESPERANTO_TTS_TIMEOUT is raised to 600s as headroom. Verified: 5 concurrent /audio/speech requests all return 200 with GPU 2 peaking at ~11.5 GB (was 16.7 GB for the TTS process alone), and the previously failed episode now completes end to end — 38/38 batches, 10:56 min of audio, zero OOM. Docs record both failure signatures side by side, since ConnectError (server dead) and HTTP 500 (server alive, out of VRAM) have very different remedies. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> 2026-07-11 13:02:32 +02:00			`[Unit]`
			`Description=Open Notebook STT (faster-whisper, OpenAI-compatible wrapper on :8902)`
			`After=network.target`

			`[Service]`
			`Type=simple`
			`WorkingDirectory=%h/open-notebook/services`
			`ExecStart=%h/miniforge3/bin/python3 stt_server.py`
			`Restart=on-failure`
			`RestartSec=5`
			`StandardOutput=journal`
			`StandardError=journal`
			`Environment="STT_HOST=0.0.0.0"`
			`Environment="STT_PORT=8902"`
			`# GPU 2 eindeutig per UUID, NICHT per Index — siehe Kommentar in`
			`# open-notebook-tts.service.`
			`Environment="CUDA_VISIBLE_DEVICES=GPU-83ba6d1f-ebbe-f8c8-1433-153e0ebc3866"`
			`Environment="PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True"`

			`[Install]`
			`WantedBy=default.target`