[GH-ISSUE #16150] issue: TTS playback lacks proper queueing #17800

New Issue

GiteaMirror · 2026-04-19T23:41:12-05:00

GiteaMirror commented

2026-04-19 23:41:12 -05:00

Originally created by @jcbyte on GitHub (Jul 30, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16150

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

0.6.18

Ollama Version (if applicable)

No response

Operating System

Windows 11

Browser (if applicable)

Chrome 138.0.7204.169

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

Clicking the "Read aloud" button on a message should begin tts playback for that message.
If another messages "Read aloud" button is clicked before the first message has finished playing, the second message should be queued and played only after the first message has either completed or been manually cancelled.

Actual Behavior

When clicking on the the second "Read aloud" on another message before the first has stopped.

If using Web API tts:

This second message is played afterwards as hoped but if the first message is cancelled then the second will never play.

If using OpeanAI (or tts that plays blobs):

The second message is played on top of the already playing message.

When clicking the "Read aloud" button on a second message before the first has finished playing:

Using Web API TTS:

The second message is correctly queued and played after the first.
However, if either message is cancelled, playback completely stops, and the queue appears to be dropped.

Using OpenAI TTS (or TTS that play audio blobs):

The second message begins playing immediately, overlapping with the first message.
This results in both messages being played simultaneously, creating unintelligible audio output.

Steps to Reproduce

Clone the Open WebUI repo and install all required dependencies.
Run both the frontend and backend locally.
Start a conversation and ensure there are at least two separate messages.
Open Admin Panel -> Settings -> Audio -> Text-to-Speech Engine, and select:
a. OpenAI (with valid key) to see overlapping audio playback.
b. Web API to see the unintended cancelation behaviour.
Click the "Read aloud" button on the first message.
Before the first message finishes, click "Read aloud" on the second message.

Logs & Screenshots

This is unrelated/not applicable

Additional Information

Bug was discovered while working on implementing SSML voice blocks for mixed narration support in Open WebUI.

Originally created by @jcbyte on GitHub (Jul 30, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/16150 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version 0.6.18 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 ### Browser (if applicable) Chrome 138.0.7204.169 ### 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. - [ ] I have included the browser console logs. - [ ] 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 Clicking the "Read aloud" button on a message should begin tts playback for that message. If another messages "Read aloud" button is clicked before the first message has finished playing, the second message should be queued and played only after the first message has either completed or been manually cancelled. ### Actual Behavior When clicking on the the second "Read aloud" on another message before the first has stopped. If using Web API tts: - This second message is played afterwards as hoped but if the first message is cancelled then the second will never play. If using OpeanAI (or tts that plays blobs): - The second message is played on top of the already playing message. When clicking the "Read aloud" button on a second message before the first has finished playing: Using Web API TTS: - The second message is correctly queued and played after the first. - However, if either message is cancelled, playback completely stops, and the queue appears to be dropped. Using OpenAI TTS (or TTS that play audio blobs): - The second message begins playing immediately, overlapping with the first message. - This results in both messages being played simultaneously, creating unintelligible audio output. ### Steps to Reproduce 1. Clone the Open WebUI repo and install all required dependencies. 2. Run both the frontend and backend locally. 3. Start a conversation and ensure there are at least two separate messages. 4. Open Admin Panel -> Settings -> Audio -> Text-to-Speech Engine, and select: a. OpenAI (with valid key) to see overlapping audio playback. b. Web API to see the unintended cancelation behaviour. 5. Click the "Read aloud" button on the first message. 6. Before the first message finishes, click "Read aloud" on the second message. ### Logs & Screenshots This is unrelated/not applicable ### Additional Information Bug was discovered while working on implementing SSML voice blocks for mixed narration support in Open WebUI.

GiteaMirror added the bug label 2026-04-19 23:41:12 -05:00

GiteaMirror closed this issue

2026-04-19 23:41:13 -05:00

GiteaMirror referenced this issue

2026-04-20 00:37:04 -05:00

[GH-ISSUE #17800] issue: Pipeline HTML responses always end up in a too-short iframe because client strips scripts & resets height #18400

GiteaMirror referenced this issue

2026-04-25 07:48:39 -05:00

[GH-ISSUE #17800] issue: Pipeline HTML responses always end up in a too-short iframe because client strips scripts & resets height #33929

GiteaMirror referenced this issue

2026-05-05 20:33:21 -05:00

[GH-ISSUE #17800] issue: Pipeline HTML responses always end up in a too-short iframe because client strips scripts & resets height #57066