mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[GH-ISSUE #24169] issue: STT halts the server untill finished #58885
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#58885
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Mastersomy on GitHub (Apr 27, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24169
Check Existing Issues
Installation Method
Docker
Open WebUI Version
0.9.2
Ollama Version (if applicable)
No response
Operating System
server is on Ubuntu 24.04 client is on Windows 11
Browser (if applicable)
Firefox 148.0 and Edge 147.0.3912.86
Confirmation
README.md.Expected Behavior
when somewone in the instance uses stt that stt will get processed and nobody else is disrupted while using owui.
Actual Behavior
when stt is beeing used the server process halts untill processing is finisched (or more likly the server process is the one processing the stt)
that producess timeouts (for all users of that instance) when someone makes a stt that takes long to process (cpu inference or inference overload)
Steps to Reproduce
setup OWUI with only a cpu
setup https to be able to use stt
setup stt with a larger model (large-v3 for example)
make a dictation thhat is 30 or so seconds log
while transcribing it the server will not awwnser any web requests.
Logs & Screenshots
browser logs:
websocket.js:119 WebSocket connection to 'wss://xxxxxxxxxxx/ws/socket.io/?EIO=4&transport=websocket' failed: createSocket @ websocket.js:119 doOpen @ websocket.js:24 open @ transport.js:47 _open @ socket.js:197 constructor @ socket.js:150 constructor @ socket.js:565 constructor @ socket.js:725 open @ manager.js:111 (anonymous) @ manager.js:337 websocket.js:119 WebSocket connection to 'wss://xxxxxxxxxxx/ws/socket.io/?EIO=4&transport=websocket' failed: createSocket @ websocket.js:119 doOpen @ websocket.js:24 open @ transport.js:47 _open @ socket.js:197 constructor @ socket.js:150 constructor @ socket.js:565 constructor @ socket.js:725 open @ manager.js:111 (anonymous) @ manager.js:337 websocket.js:119 WebSocket connection to 'wss://xxxxxxxxxxxxxx/ws/socket.io/?EIO=4&transport=websocket' failed: createSocket @ websocket.js:119 doOpen @ websocket.js:24 open @ transport.js:47 _open @ socket.js:197 constructor @ socket.js:150 constructor @ socket.js:565 constructor @ socket.js:725 open @ manager.js:111 (anonymous) @ manager.js:337 fetcher.js:77 GET https://xxxxxxxxxxxxxx/_app/version.json net::ERR_HTTP2_PROTOCOL_ERROR (anonymous) @ fetcher.js:77 check @ utils.js:272 setTimeout create_updated_store @ utils.js:298 (anonymous) @ client.js:129 index.ts:75 POST https://xxxxxxxxxxxxxxx/api/v1/audio/transcriptions net::ERR_CONNECTION_REFUSED (anonymous) @ fetcher.js:77 (anonymous) @ index.ts:75 (anonymous) @ VoiceRecording.svelte:186 await in (anonymous) (anonymous) @ VoiceRecording.svelte:274 websocket.js:119 WebSocket connection to 'wss://xxxxxxxxxxxxx/ws/socket.io/?EIO=4&transport=websocket' failed:Docker logs entsprechend dem fehler:
2026-04-27 05:22:36.867 | INFO | open_webui.routers.audio:transcription:1234 - file.content_type: audio/webm;codecs=opus 2026-04-27 05:22:36.874 | INFO | open_webui.routers.audio:transcribe:1102 - transcribe: /app/backend/data/cache/audio/transcriptions/23fe 9bf1-3566-4043-a427-2657f6b13cbd.webm None 2026-04-27 05:22:38.241 | INFO | open_webui.routers.audio:convert_audio_to_mp3:123 - Converted /app/backend/data/cache/audio/transcriptio ns/23fe9bf1-3566-4043-a427-2657f6b13cbd.webm to /app/backend/data/cache/audio/transcriptions/23fe9bf1-3566-4043-a427-2657f6b13cbd.mp3 Chunk paths: ['/app/backend/data/cache/audio/transcriptions/23fe9bf1-3566-4043-a427-2657f6b13cbd.mp3'] 2026-04-27 05:22:48.199 | INFO | faster_whisper.transcribe:transcribe:881 - Processing audio with duration 00:05.160 2026-04-27 05:23:06.158 | INFO | faster_whisper.transcribe:transcribe:948 - Detected language 'de' with probability 0.97 2026-04-27 05:23:06.177 | INFO | open_webui.routers.audio:transcription_handler:660 - Detected language 'de' with probability 0.968905Additional Information
we are currently in the evaluation of openwebui and because of that we are using large-v3 to gage the quality that will be produced once we deploy for real.
@Classic298 commented on GitHub (May 1, 2026):
In backend/open_webui/routers/audio.py the
transcriptionendpoint at line 1221 isasync defbut calls the synchronoustranscribe(...)at line 1269 directly, which then gathers ThreadPoolExecutor chunk results via blockingfuture.result()at line 1138. WithUVICORN_WORKERS=1(the default in start.sh) one event loop serves HTTP and Socket.IO, so while faster-whisper runs uvicorn cannot accept anything else, which is exactly what yourECONNREFUSEDand dropped websockets show. Your own log has 18s of inference for 5.16s of audio so a 30s clip is roughly two minutes of total stall.Quick patch worth trying before anything else. In backend/open_webui/routers/audio.py:
Add to the imports near the top:
import asyncio
Replace line 1250
contents = file.file.read()
with
contents = await file.read()
Replace line 1269
result = transcribe(request, file_path, metadata, user)
with
result = await asyncio.to_thread(transcribe, request, file_path, metadata, user)
Rebuild the image or bind mount the patched file into the container and reproduce. If other users can keep using the UI while a transcription is still running then the blocking route was the cause and STT itself is fine, just slow on CPU.
If it still misbehaves please share
UVICORN_WORKERS, host CPU count and RAM,findmnt -T /app/backend/datafrom inside the container, yourDATABASE_URLsetup (especially whether the data dir lives on NFS or another network mount), and ideally apy-spy dump --pid <uvicorn-pid>captured during a freeze. That should be enough to nail down whatever is left.@Mastersomy commented on GitHub (May 3, 2026):
I tested it and there where no more disconnections. also long transcriptions that caused openwebui to notice that the connections was dropped wouldn't even appear in the chatui but with those changes i can't find a problem anymore.
As a test after making this issue we tryed to use a openai compatible server for stt and there was the same problem. I retested that now with positive results it works also for that.
@Classic298 commented on GitHub (May 3, 2026):
@Mastersomy what exactly of the options is what you tested successfully?
@Mastersomy commented on GitHub (May 3, 2026):
ok my test setup and what tests i performed:
i run 2 openwebui instances the one used in this testing is on unraid the other one is a vm at work with docker.
the one on unraid is super simple just mounted the data path to a local folder and a port exposed using nginxproxymanager to get https.
i used docker volume mount to patch the file with the lines @Classic298 mentioned.
after that i opened the instance with two devices (my ipad and my desktop)
set the stt to local whisper using the large-v3 model
then i Opend a new chat on my desktop and clicked the microphone and talked for a short while.
after kicking the check mark to end the transcription before i could not do anything on the ipad after the patch the ipad was unaffected (maybe a little slower to load but that would be expected when the cpu on the server is at 100%)
at work we tested if it would make a difference if we would use a separate openai compatible stt server.
the short version is that it behaves exactly like the local version. before the changes from @Classic298 you can't even load the site on a seperate device after the change I can't tell if there is a transcription ongoing by another device.
so the @Classic298 mentioned work to fix my issue.
@Classic298 commented on GitHub (May 3, 2026):
Ok thanks for testing I'll PR it then