Stefan's Gamebox ist Windows (kein SSH-Zugriff), und in Zukunft
koennten whisper/f5tts auf separaten Hosts laufen. Wir brauchen
deshalb einen Logging-Pfad ueber RVS — gleicher Mechanismus wie
fuer die App (reportAppDebug).
Beide Bridges senden jetzt app_log-Messages mit platform="whisper"
bzw. "f5tts". aria-bridge schreibt sie in /shared/logs/app.log
(unverändert), Live-Logs-Tab + Diagnostic /api/app-log lesen mit.
Toggle via aria-bridge config:
whisperDebugLog: bool — default OFF (aktuell aber ON in
whisper-bridge weil wir Phase-1/2-
Pipeline einfahren)
f5ttsDebugLog: bool — default OFF
Beide werden in voice_config.json persistiert + nach RVS-Connect
rebroadcastet, damit Toggle Container-Restart ueberlebt.
Whisper-Bridge logt aktuell:
boot → Streaming-Mode-Marker (sehen wir damit ob
neue Version aktiv ist)
stream.start → stt_stream_start angekommen
stream.chunk → alle 25 Chunks (=5s Audio) einer
stream.chunk.reject → Chunk fuer unbekannte Session
stream.partial → Whisper hat neuen Text erkannt
stream.final → Endpoint detected, finaler Text raus
stream.end → stt_stream_end angekommen
config → Toggle umgeschaltet
F5TTS-Helper ist da (gleicher Pattern), Logging-Punkte kommen
spaeter wenn wir ein konkretes TTS-Problem zu debuggen haben.
Neue RVS-Messages auf der Whisper-Bridge:
stt_stream_start {requestId, audioRequestId, language?, model?,
endpointMs?=1500, hardCapMs?=60000, voice, speed,
interrupted, location, sampleRate?=16000}
stt_audio_chunk {requestId, pcm: base64-s16le, seq}
stt_stream_end {requestId, reason}
stt_partial (Bridge→App, alle ~700ms, fuer Live-UI-Feedback)
stt_endpoint (Bridge→App+aria-bridge, finaler Text + alle Echos)
stt_stream_done (Bridge→App, signalisiert Session-Ende)
Endpointer-Logik:
- alle 700ms transkribiert die Bridge den Ringbuffer (beam_size=1, schnell)
- waechst der Transkript-String → Stagnation-Timer reset
- waechst er nicht → bei endpointMs ohne Wachstum: finalisiert
- bei hardCapMs (60s) sowieso finalisiert egal ob stagnierend
- Final-Transcribe nochmal mit beam_size=5 fuer Qualitaet
- stt_endpoint enthaelt voice/speed/interrupted/location echos,
damit aria-bridge in Phase 2 direkt an Brain weiterleiten kann
Legacy stt_request (One-Shot mit base64-mp4/wav) bleibt unveraendert
als Fallback.
Default-Parameter (alle vom App-Payload uebersteuerbar):
STREAM_TRANSCRIBE_INTERVAL_MS = 700 (Throttle)
STREAM_DEFAULT_ENDPOINT_MS = 1500 (Stille = kein neuer Text)
STREAM_DEFAULT_HARD_CAP_MS = 60000 (Schmerzgrenze)
STREAM_MIN_AUDIO_MS = 600 (erst transkribieren ab N Audio)
STREAM_SESSION_TTL_S = 120 (tote Sessions aufraeumen)
Ersetzt den dB/VAD-Stille-Trigger auf der App-Seite — Endpointer
hoert auf SEMANTISCHE Stille (kein neuer Text), nicht akustische.
Funktioniert im Auto / mit Musik im Hintergrund / in lauten
Umgebungen wo VAD versagt.
Stefan-Bug-Report: Diagnostic zeigt seit Tagen 'XTTS-Server: Nicht
verbunden (starte xtts/ auf dem Gaming-PC)' obwohl der Container
laeuft. Keine TTS-Ausgabe, keine STT-Eingabe.
Ursache: exakt der gleiche Sticky-TLS-Fallback-Bug den wir vor ein
paar Tagen bei aria-bridge (commit b5ca3cd) und Android-App (commit
ad87c80) gefixt hatten — die xtts/whisper- und xtts/f5tts-Bridges
sind aber separate Codebases auf der Gamebox und wurden uebersehen.
Mechanik:
1. RVS hatte mal kurzen TLS-Hick (z.B. Caddy-Restart oder Port-Wechsel
443 → 444 vor Tagen)
2. Bridge versucht wss:// → fail → switch auf ws:// (use_tls = False)
3. Connect klappt jetzt nicht mehr (RVS-Port hatte sich geaendert)
4. Reconnect-Loop bleibt auf ws://, kommt NIE mehr auf wss zurueck
5. Container laeuft, RVS-Status 'nicht verbunden'
Fix: nach jedem Disconnect-Sleep `use_tls = RVS_TLS` und
`tls_fallback_tried = False` zuruecksetzen. Bei jedem Reconnect-
Cycle wird wss neu probiert; falls das wieder failt, switcht's
sauber auf ws fuer den naechsten Versuch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
f5tts/bridge.py: das hardcoded model="small" in request_transcription war
ein Fehler — whisper-bridge hat dadurch stumm zwischen Modellen geswappt.
Wenn User large-v3 in Diagnostic eingestellt hatte:
- f5tts Voice-Transkribierung triggerte Swap zu "small" (+~500MB Laden)
- Danach aria-bridge schickte naechsten stt_request mit large-v3
(+~3GB Laden weil small jetzt im RAM war)
Doppelter Load, unnoetiger Traffic.
Fix:
- f5tts: kein model mehr im payload, whisper-bridge entscheidet
- whisper: wenn kein payload.model UND bereits ein Modell geladen →
das behalten. Nur wenn gar nichts da ist fallback auf WHISPER_MODEL
env default.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Beim user kommt nach 'RVS verbunden' nichts mehr — Modell-Download
startet nicht, banner aktualisiert sich nicht. Vermutung: alter Code
laeuft noch (kein neu gebauter Container) ODER der Initial-Handshake
crashed silent (asyncio.create_task ohne await schluckt Exceptions).
- whisper + f5tts: Initial-Handshake mit logger.info Zeilen, damit
man sieht ob er ueberhaupt ausgefuehrt wird
- f5tts: zusaetzlich exception-Catch + fehler-broadcast falls der
Modell-Load crashed
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vier Bugs in einem Aufwasch:
1. HF-Cache als Bind-Mount zurueck
xtts/hf-cache:/root/.cache/huggingface fuer beide Bridges. War vorher
raus, dadurch jedes Container-Restart = ~3GB Whisper-Download +
~1GB F5-TTS-Download. User dachte 5min ist einmalig — ist aber bei
jedem Restart. Jetzt: einmal pro Maschine geladen, fertig.
2. Banner zeigte stale "ready"
whisper-bridge sendete beim Connect nur dann Status wenn Modell schon
geladen war. Sonst blieb der App/Diagnostic Banner auf dem alten
"ready" State von vor dem Restart haengen — User sah "bereit" obwohl
gerade gar nichts geladen war. Jetzt wird IMMER ein Status broadcast:
ready oder loading.
3. config_request Pattern
aria-bridge wusste nicht wann Gamebox-Bridges sich (re)connecten.
Wenn die nach aria-bridge kamen, verpassten sie den Config-Broadcast
und blieben mit Hard-Defaults stehen.
Jetzt: whisper- und f5tts-bridge senden beim Connect ein
config_request, aria-bridge antwortet mit der persistierten Config
(whisperModel, xttsVoice, f5tts*-Felder).
4. RVS ALLOWED_TYPES um config_request erweitert.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Symptom: aria-whisper-bridge bekam beim ersten internen stt_request
(via voice_upload mit WAV als base64, ~2.4MB) den Frame zu Gesicht,
default ws-max ist 1MB → mit Close-Code 1009 abgewiesen → Verbindung
tot → naechster stt_request lief in Timeout → lokales Fallback.
Fixes:
- whisper-bridge: max_size=50*1024*1024 in websockets.connect()
(gleicher Wert wie f5tts-bridge schon hat)
- RVS-Server: maxPayload=50*1024*1024 in WebSocketServer-Optionen,
damit der Server die Frames nicht selbst auf 1MB cappt bevor er
sie an die Bridge weiterleitet.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vorher: Container-Start lud erst 'small' (env default), dann nochmal
das in Diagnostic konfigurierte Modell (z.B. large-v3) wenn die
config-Broadcast vom aria-bridge ankam. Doppelter Download, doppelte
Wartezeit, doppelter VRAM-Peak.
Jetzt:
- Initial wird NICHTS geladen
- aria-bridge sendet die persistierte voice_config.json kurz nach
RVS-Connect → whisper-bridge sieht den richtigen Modellnamen
- config-Handler erkennt: noch nichts geladen ODER Wechsel
→ loading-Broadcast → ensure_loaded → ready-Broadcast
- stt_request-Handler: gleicher Status-Broadcast falls Race-Condition
(Spracheingabe in den ersten 1-2s nach Container-Start)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Stefan akzeptiert die ~5min Modell-Download-Zeit nach jedem Container-
Start, dafuer keine 50GB Cache-Bloat mehr und kein Bind-Mount-Verzeichnis
zu pflegen.
- xtts/docker-compose.yml: hf-cache Bind-Mount entfernt fuer beide
Bridges. Modelle werden im writable Container-Layer abgelegt und mit
jedem `docker compose down` automatisch weggeraeumt.
- xtts/.gitignore: hf-cache/ Eintrag raus
- RVS ALLOWED_TYPES: service_status hinzu
Bridges broadcasten Lade-Status:
- f5tts-bridge: bei Connect 'loading' -> ensure_loaded -> 'ready'.
Auch bei config-getriggertem Modell-Wechsel: erst 'loading' Broadcast,
dann reload, dann 'ready'.
- whisper-bridge: gleiches Pattern. Modell wird jetzt erst nach
RVS-Connect geladen damit der loading-Broadcast tatsaechlich rausgeht.
Diagnostic:
- server.js: service_status wird an Browser durchgereicht
- index.html: neues Banner unten rechts (fixed position) zeigt Status
fuer beide Services. Aggregiert: Icon ist Lupe waehrend Loading,
Check wenn alles ready, X bei Error.
- Wenn alles ready: X-Button erscheint (manuell schliessen) +
nach 8s automatisches Fade-Out.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Neuer Container aria-whisper-bridge auf der Gamebox — faster-whisper
CUDA mit float16. Der Container verbindet sich per WebSocket an den RVS,
nimmt stt_request entgegen, laeuft ffmpeg+Whisper, antwortet mit
stt_response. Hoert zusaetzlich auf config-Broadcasts und lädt das
Modell hot-swap bei Diagnostic-Wechsel.
aria-bridge ruft jetzt primaer die Gamebox an; nur wenn die nicht binnen
45s antwortet, faellt auf lokales Whisper (CPU) zurueck. Das lokale
Modell wird lazy geladen, spart RAM auf der VM.
RVS: stt_request/stt_response zur ALLOWED_TYPES-Liste.
Diagnostic-Voice-Config (whisperModel-Feld) bleibt unveraendert —
die Auswahl wird an die Gamebox durchgereicht.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
duffyduck