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>
This commit is contained in:
parent
054f867a8a
commit
03877588e1
8 changed files with 244 additions and 52 deletions
|
|
@ -136,8 +136,7 @@ geklonten echten Personen, siehe [`CLAUDE.md`](CLAUDE.md)).
|
|||
2. Datei nach `services/voices/<name>.wav` legen (z. B. `services/voices/elena.wav`).
|
||||
3. TTS-Server neu starten (Stimmen werden nur beim Start eingelesen):
|
||||
```bash
|
||||
pkill -f "python tts_server.py"
|
||||
./scripts/start_services.sh
|
||||
systemctl --user restart open-notebook-tts
|
||||
```
|
||||
4. Prüfen: `curl http://127.0.0.1:8901/health` sollte `<name>` in der `voices`-Liste zeigen.
|
||||
5. In einem Sprecherprofil (Podcast) den betreffenden Sprecher auf `voice_id: "<name>"` setzen,
|
||||
|
|
@ -207,12 +206,17 @@ Weitere OpenRouter-Modelle lassen sich jederzeit über `POST /api/models` regist
|
|||
docker compose up -d
|
||||
docker compose down
|
||||
|
||||
# TTS/STT (lokale Hintergrundprozesse, nicht in Docker)
|
||||
./scripts/start_services.sh
|
||||
pkill -f "python tts_server.py"
|
||||
pkill -f "python stt_server.py"
|
||||
# TTS/STT (auf dem Host, nicht in Docker — systemd-User-Dienste)
|
||||
systemctl --user status open-notebook-tts open-notebook-stt
|
||||
systemctl --user restart open-notebook-tts open-notebook-stt
|
||||
systemctl --user stop open-notebook-tts open-notebook-stt
|
||||
journalctl --user -u open-notebook-tts -f # Logs
|
||||
```
|
||||
|
||||
TTS/STT starten nach einem Reboot **automatisch** mit. Nur bei der Ersteinrichtung (oder nach
|
||||
Änderungen an `services/systemd/*.service`) einmal `./scripts/start_services.sh` ausführen — das
|
||||
installiert die Unit-Dateien und aktiviert den Autostart.
|
||||
|
||||
Ollama selbst läuft als systemd-Dienst und muss normalerweise nicht manuell verwaltet werden:
|
||||
|
||||
```bash
|
||||
|
|
@ -368,8 +372,8 @@ Such-/Ask-Funktion oder „nur Erkenntnisse" nach einer Zusammenfassung nutzen.
|
|||
docker compose exec open_notebook curl -sf http://host.docker.internal:8901/health
|
||||
```
|
||||
|
||||
Bei Timeout: `ufw`-Regeln fehlen (siehe README 2.4) oder die Server laufen nicht
|
||||
(`./scripts/start_services.sh`).
|
||||
Bei Timeout: `ufw`-Regeln fehlen (siehe README 2.4) oder die Dienste laufen nicht
|
||||
(`systemctl --user status open-notebook-tts open-notebook-stt`).
|
||||
|
||||
### Podcast-Profil zeigt „Einrichtung erforderlich"
|
||||
|
||||
|
|
@ -410,6 +414,32 @@ wird abgeschnitten. Behoben durch `/no_think` als erste Zeile beider Podcast-Vor
|
|||
den Denkmodus ab, ~3× schneller, volles Budget fürs JSON). Falls es dennoch auftritt: kürzeren
|
||||
Quellinhalt verwenden (nicht das ganze Buch) oder die Generierung erneut starten.
|
||||
|
||||
### Podcast schlägt beim Vertonen fehl („Failed to generate speech")
|
||||
|
||||
Text und Transkript sind fertig, erst die Sprachausgabe scheitert. Die genaue Fehlermeldung
|
||||
(UI-Episodenliste oder `docker compose logs open_notebook`) unterscheidet **zwei verschiedene
|
||||
Ursachen** — die Verwechslung kostet sonst viel Zeit:
|
||||
|
||||
| Meldung | Bedeutung | Abhilfe |
|
||||
|---|---|---|
|
||||
| `All connection attempts failed` (`ConnectError`) | Der TTS-Server **läuft nicht** — niemand nimmt den Request an. | `systemctl --user status open-notebook-tts`, ggf. `restart`. |
|
||||
| `OpenAI-compatible TTS endpoint error: HTTP 500` | Der TTS-Server **lebt**, bricht aber bei der Arbeit ab — meist `CUDA out of memory`. | `journalctl --user -u open-notebook-tts -n 50` prüfen. |
|
||||
|
||||
Der GPU-Speicherfall entstand so: GPU 2 teilen sich drei Prozesse (TTS, STT und der separate
|
||||
`chatterbox-tts`-MCP-Dienst auf Port 9999), es bleiben nur ~12 GB übrig. Der Podcast-Generator
|
||||
schickte aber 5 Clips gleichzeitig, die im TTS-Server echt parallel auf derselben GPU liefen —
|
||||
der Speicherbedarf vervielfachte sich (bis 16,7 GB) und sprengte die Karte. Behoben durch zwei
|
||||
Maßnahmen: `tts_server.py` serialisiert seine Generierung intern (ein Clip zur Zeit — auf einer
|
||||
einzelnen GPU kostet das keinen Durchsatz), und `TTS_BATCH_SIZE=1` in `docker-compose.yml` sorgt
|
||||
dafür, dass gar nicht erst mehrere Anfragen gleichzeitig eintreffen. Ein fehlgeschlagener Podcast
|
||||
lässt sich anschließend ohne Neuanlage wiederholen:
|
||||
|
||||
```bash
|
||||
curl -X POST http://127.0.0.1:5055/api/podcasts/episodes/{episode_id}/retry
|
||||
```
|
||||
|
||||
(Der Retry legt einen neuen Episoden-Eintrag an; der alte, fehlgeschlagene verschwindet.)
|
||||
|
||||
### Weitere technische Details
|
||||
|
||||
Siehe [`CLAUDE.md`](CLAUDE.md) — dort stehen alle bisher aufgetretenen Probleme mit exakter
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue