WhisperX transcription returns only hallucinated filler ("Thank you.") — the identical command works when run by hand, and Scriberr's subprocess never touches the GPU

Start by tracing how Scriberr constructs the WhisperX subprocess, especially the child cmd.Env, and compare that environment with the manual invocation. Check the startup model initialization and JSON parsing paths mentioned in the report. Done means Scriberr's child process uses the configured GPU and returns the full transcript for the byte-identical WAV.

Summary

Every transcription through Scriberr returns a handful of tiny hallucinated segments (" Thank you." / " you.") instead of the real speech, regardless of model size, VAD method, or whether diarization is on. The audio is fine and the exact WhisperX command Scriberr logs — run manually inside the same container, on the byte-identical converted WAV — produces the full, correct transcript. The one observable difference: when Scriberr runs WhisperX, the subprocess never allocates any GPU memory (nvidia-smi VRAM stays flat), whereas a manual run of the same command does.

Environment

• Image: ghcr.io/rishikanthc/scriberr-cuda:latest (pulled July 2026)
• Docker, runtime: nvidia, NVIDIA_VISIBLE_DEVICES=all, PUID=99/PGID=100
• GPU: GTX 1660 SUPER (6 GB, Turing); nvidia-smi -L works inside the container as appuser (uid 99)
• WhisperX 3.0.0, --compute_type int8, --device cuda
• Input: normal phone .m4a, ~86 s, mean −25.9 dB / peak −0.6 dB (clearly audible speech)

Symptom

{"text":" Thank you.  Thank you.  Thank you.",
 "segments":[{"start":9.183,"end":9.723,"text":" Thank you."}, ...],
 "model_used":"large-v3","metadata":{"model_id":"whisperx","model_version":"3.0.0","device":"cuda"}}

Scriberr logs segments=3 words=6 for an 86 s clip containing a full conversation.

Exact command Scriberr runs (from its logs)

uv run --native-tls --project /app/whisperx-env/WhisperX python -m whisperx \
  /app/data/uploads/<id>_converted.wav --output_dir data/temp/whisperx/<id> \
  --model large-v3 --device cuda --device_index 0 --batch_size 8 --compute_type int8 \
  --output_format all --verbose True --task transcribe --language en \
  --vad_method pyannote --vad_onset 0.500 --vad_offset 0.363 \
  --diarize --diarize_model pyannote/speaker-diarization-3.1 \
  --temperature 0.00 --best_of 5 --beam_size 5 --patience 1.00 \
  --hf_token <HF_TOKEN> --print_progress False

What I ruled out

All of these still produce garbage through Scriberr:

Profile change	Result via Scriberr
model large-v3 → medium → small	garbage (all)
VAD pyannote → silero	garbage (both)
diarization on → off	garbage (both)

Audio/file is provably fine: Scriberr's <id>_converted.wav is correct 16 kHz mono PCM, full length, normal levels, and byte-identical (same md5) across runs. faster-whisper on the same audio → full correct transcript.

The smoking gun

Running Scriberr's exact logged command by hand on Scriberr's byte-identical converted WAV gives the full correct transcript every way I tried:

Invocation	GPU used?	Result
By Scriberr	No (VRAM flat)	" Thank you." ×3
Manual --device cuda, as root	Yes	✅ full transcript
Manual --device cuda, as appuser (uid 99) (same user Scriberr uses)	Yes	✅ full transcript
Manual --device cpu	n/a	✅ full transcript

Same command, same file (md5 match), same container, same user → works by hand, fails under Scriberr. During a Scriberr job the WhisperX subprocess is running (pgrep -f "python -m whisperx") but nvidia-smi --query-compute-apps shows it is not on the GPU. Scriberr does not set CUDA_VISIBLE_DEVICES (no device-masking env in the binary), and the GPU nodes are world-accessible.

Repro

1. Transcribe any multi-minute recording with a WhisperX device=cuda profile.
2. Output = repeated " Thank you.", segments tiny.
3. During the job: nvidia-smi --query-compute-apps=... → WhisperX not on GPU.
4. Grab the temp <id>_converted.wav, run the exact logged command by hand → correct transcript, GPU used.

Hypothesis / ask

Something about how Scriberr spawns the WhisperX subprocess prevents it from engaging CUDA (and it then transcribes ~nothing rather than erroring). Worth checking: the cmd.Env passed to the child vs. an interactive shell; whether the startup "Initializing registered models in parallel" leaves CUDA/torch in a bad state the child inherits; and how the produced JSON is parsed back.

Workaround

Setting the profile to device=cpu transcribes correctly (CPU is only modestly slower, fine for async processing). GPU via Scriberr remains broken.

Yep... I asked Ai for help since I gave up trying to figure it out. This is what it came out with. Any help?