Discussed in #487
Originally posted by iamonlv426 August 27, 2026
Feature request
Please consider officially supporting Spotatui when its terminal UI runs inside WSL2.
Spotatui can run in WSL2, but two major problems remain:
- Native Linux audio through WSLg/PulseAudio becomes unreliable during longer sessions. Playback can begin stuttering or stall, and in some cases audio continues after the TUI exits because the playback process has not shut down cleanly.
- Cover art is not rendering as genuine Sixel in Windows Terminal. It falls back to blocky/half-block artwork even when Sixel is selected or requested.
A supported WSL2 path could include:
- stable WSLg/PulseAudio playback without progressive stuttering or stalls;
- clean shutdown of playback when Spotatui exits;
- recovery when the WSLg audio device disappears or reconnects;
- reliable Sixel capability detection and genuine Sixel artwork in Windows Terminal rather than block/half-block fallback;
- a visible diagnostic showing which image protocol Spotatui actually selected;
- consistent Windows-versus-WSL configuration paths; and
- optionally, an officially supported Windows audio backend while the UI continues to run inside WSL2.
The last option has proven the most reliable for audio in testing: run the UI from WSL2, but use a Windows-native playback engine. Formal support for that arrangement would give WSL2 users reliable Windows audio while retaining the Linux terminal experience. It does not currently solve the artwork issue.
Environment tested:
- Windows 11 with WSL2 / WSLg
- Ubuntu under WSL2
- Windows Terminal
- Spotatui 0.41.0
- attempted Sixel artwork, currently rendered as blocky/half-block output
- PulseAudio through WSLg, plus a Windows-native playback workaround
Happy to provide logs or test proposed builds.
Discussed in #487
Originally posted by iamonlv426 August 27, 2026
Feature request
Please consider officially supporting Spotatui when its terminal UI runs inside WSL2.
Spotatui can run in WSL2, but two major problems remain:
A supported WSL2 path could include:
The last option has proven the most reliable for audio in testing: run the UI from WSL2, but use a Windows-native playback engine. Formal support for that arrangement would give WSL2 users reliable Windows audio while retaining the Linux terminal experience. It does not currently solve the artwork issue.
Environment tested:
Happy to provide logs or test proposed builds.