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-25 07:14:07 -05:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @jcbyte on GitHub (Jul 30, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16150
Check Existing Issues
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
README.md.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:
If using OpeanAI (or tts that plays blobs):
When clicking the "Read aloud" button on a second message before the first has finished playing:
Using Web API TTS:
Using OpenAI TTS (or TTS that play audio blobs):
Steps to Reproduce
a. OpenAI (with valid key) to see overlapping audio playback.
b. Web API to see the unintended cancelation behaviour.
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.