[GH-ISSUE #20988] issue: Android (Chromium browsers): Voice Call mode consistently freezes after ~8–9 turns (TTS request returns 200, UI stuck). Firefox/Safari OK

Originally created by @Jordive992 on GitHub (Jan 28, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20988 ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Pip Install ### Open WebUI Version 0.7.2 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior When using Voice Call mode in OpenWebUI on Android browsers, the voice conversation should remain stable across many turns. Each turn should: capture microphone input, transcribe and send the message, generate the assistant response, synthesize and play the TTS audio, then reliably return to the listening state for the next turn, without freezing or requiring a page reload, regardless of the number of turns. ### Actual Behavior On Android Chromium-based browsers (Chrome, Edge, Opera, Samsung Internet), Voice Call mode consistently breaks after ~8–9 turns (even with short messages and even without Bluetooth/headphones). At the failure point: the user’s speech is transcribed and appears in the chat, the assistant response text is generated and visible, the server logs show the TTS endpoint returning HTTP 200, but the Call UI stays stuck in the “thinking/…” state, does not play the response audio, and stops listening for further input. The only workaround is refreshing/reloading the page, after which it works again until freezing around turn ~8–9. ### Steps to Reproduce On an Android phone, open OpenWebUI in a Chromium-based browser (Chrome / Edge / Opera / Samsung Internet). Open any chat (new or existing). Enable Voice Call mode (hands-free “Call” mode) and grant microphone permission. Perform several short voice turns: speak a short sentence, wait for transcription, wait for the assistant response to appear, wait for TTS playback, repeat. After approximately 8–9 turns, the issue occurs: the speech is transcribed and shown as a user message, the assistant response text is generated and visible, but the call UI remains stuck in the “thinking/…” state, no TTS audio plays, and it stops listening. Refresh/reload the page to recover; repeat steps 3–5 and the freeze happens again around turn 8–9. Notes: Reproduces even without Bluetooth/headphones (using phone mic/speaker). Does not reproduce on Firefox (Android) (tested 25 turns). Does not reproduce on Safari (iPhone) (tested 12+ turns) or on desktop browsers (tested 20+ turns). ### Logs & Screenshots t at the moment the call UI freezes on Android Chromium browsers, the backend still completes the request successfully: - `POST /api/chat/completed` returns 200 - `POST /api/v1/audio/speech` returns 200 (TTS request succeeds) However, on the client the call overlay remains stuck in “thinking/…”, no audio is played, and it stops listening until the page is refreshed. ### Additional Information _No response_

GiteaMirror commented

2026-04-25 09:03:40 -05:00

Owner

Originally created by @Jordive992 on GitHub (Jan 28, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20988

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
I am using the latest version of Open WebUI.

Installation Method

Pip Install

Open WebUI Version

0.7.2

Ollama Version (if applicable)

No response

Operating System

Windows 11

Browser (if applicable)

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

When using Voice Call mode in OpenWebUI on Android browsers, the voice conversation should remain stable across many turns. Each turn should:
capture microphone input,
transcribe and send the message,
generate the assistant response,
synthesize and play the TTS audio,
then reliably return to the listening state for the next turn, without freezing or requiring a page reload, regardless of the number of turns.

Actual Behavior

On Android Chromium-based browsers (Chrome, Edge, Opera, Samsung Internet), Voice Call mode consistently breaks after ~8–9 turns (even with short messages and even without Bluetooth/headphones). At the failure point:
the user’s speech is transcribed and appears in the chat,
the assistant response text is generated and visible,
the server logs show the TTS endpoint returning HTTP 200, but the Call UI stays stuck in the “thinking/…” state, does not play the response audio, and stops listening for further input. The only workaround is refreshing/reloading the page, after which it works again until freezing around turn ~8–9.

Steps to Reproduce

On an Android phone, open OpenWebUI in a Chromium-based browser (Chrome / Edge / Opera / Samsung Internet).
Open any chat (new or existing).
Enable Voice Call mode (hands-free “Call” mode) and grant microphone permission.
Perform several short voice turns:
speak a short sentence,
wait for transcription,
wait for the assistant response to appear,
wait for TTS playback,
repeat.
After approximately 8–9 turns, the issue occurs:
the speech is transcribed and shown as a user message,
the assistant response text is generated and visible,
but the call UI remains stuck in the “thinking/…” state, no TTS audio plays, and it stops listening.
Refresh/reload the page to recover; repeat steps 3–5 and the freeze happens again around turn 8–9.
Notes:
Reproduces even without Bluetooth/headphones (using phone mic/speaker).
Does not reproduce on Firefox (Android) (tested 25 turns).
Does not reproduce on Safari (iPhone) (tested 12+ turns) or on desktop browsers (tested 20+ turns).

Logs & Screenshots

t at the moment the call UI freezes on Android Chromium browsers, the backend still completes the request successfully:

POST /api/chat/completed returns 200
POST /api/v1/audio/speech returns 200 (TTS request succeeds)
However, on the client the call overlay remains stuck in “thinking/…”, no audio is played, and it stops listening until the page is refreshed.

Additional Information

GiteaMirror added the bug label 2026-04-25 09:03:40 -05:00

GiteaMirror closed this issue

2026-04-25 09:03:41 -05:00

[GH-ISSUE #20988] issue: Android (Chromium browsers): Voice Call mode consistently freezes after ~8–9 turns (TTS request returns 200, UI stuck). Firefox/Safari OK #34881