bug(v1.1.0): splash screen never closes on Linux (COPR + AUR), main window never opens

[InstaZDLL]

Summary

WaveFlow v1.1.0 is broken on Linux: the splash screen stays on screen indefinitely and the main window never opens. Reproduced on:

• Fedora 44 via the COPR package copr:instazdll/waveflow (waveflow-0:1.1.0-1.fc44.x86_64)
• Arch / CachyOS via the AUR package waveflow-bin

The Windows installer (*-setup.exe) of the same v1.1.0 release works fine on a Windows 11 VM, so this is Linux-specific.

Symptoms

• The splash screen (added in feat(ui): splash screen to mask cold-start delay #26) renders correctly.

• The main window never replaces it — the splash stays up "forever".

• The audio engine starts before the window: cpal output stream opened sample_rate=44100 channels=2 sample_format=F32.

• Immediately after, the cpal callback floods stderr with BufferUnderrun warnings every ~50 ms:

  2026-05-17T22:21:37.234280Z  WARN waveflow_lib::audio::output: cpal stream error err=BufferUnderrun
  2026-05-17T22:21:37.277235Z  WARN waveflow_lib::audio::output: cpal stream error err=BufferUnderrun
  …(loop)
  

• libayatana-appindicator-WARNING **: libayatana-appindicator is deprecated. Please use libayatana-appindicator-glib in newly written code. (probably unrelated, just noise).

Suspected causes

A few v1.1.0 changes look load-bearing for the splash → main handoff:

• a4fdaa9 — fix(audio): keep splash close from stopping playback
• feat(ui): splash screen to mask cold-start delay #26 — splash screen introduction
• The splash window has transparent: true in src-tauri/tauri.conf.json, which forces an alpha-capable EGL config that some WebKitGTK builds reject (we already have a memory note about EGL_BAD_PARAMETER on WebKitGTK 2.52+ AppImages, see bug: Dark mode crash #34).

The continuous BufferUnderrun is the smoking gun that the audio thread is alive but never receives samples because the decoder is idle — consistent with the main window never spawning, so the user can never queue a track.

Affected channels

• ❌ Fedora COPR (dnf install waveflow)
• ❌ Arch AUR (yay -S waveflow-bin)
• ✅ Windows *-setup.exe (1.0.0 unaffected, 1.1.0 also fine on Windows)
• ❓ Debian/Ubuntu apt repo (newly added in feat(apt): publish .deb to Buildkite Packages registry on release #40, not yet user-tested)
• ❓ AppImage (already known broken on WebKitGTK 2.52+ via bug: Dark mode crash #34; v1.0.0 also affected, not a regression)

Severity

Blocker for v1.1.0 on Linux — every Linux user upgrading from v1.0.0 lands on an unusable splash loop. We should either:

1. Ship a v1.1.1 hotfix that disables the splash on Linux (fastest), or
2. Root-cause the handoff bug and ship a proper fix, or
3. Both.

Reproduction

# Fedora 44
sudo dnf copr enable instazdll/waveflow
sudo dnf install waveflow
waveflow
# → splash stays, no main window, BufferUnderrun spam in stderr

# Arch
yay -S waveflow-bin
waveflow
# → same symptom

Workaround

Downgrade to v1.0.0:

• Fedora: sudo dnf downgrade waveflow-1.0.0 (if the older RPM is still in the COPR archive)
• Arch: install the v1.0.0 release .tar.gz from GitHub Releases manually

[InstaZDLL]

New datapoint: Ubuntu — first launch KO, second launch OK

Reproduced on Ubuntu 24.04 via the new apt repo (apt install wave-flow):

• First launch after install: same symptom as Fedora/Arch — splash hangs, no main window.
• Second launch (after killing the hung process): works fine, main window opens normally.

This pattern strongly suggests a timing race in the splash → main-window handoff, not a rendering/EGL issue:

• First launch does the heavy one-time work (create profile, run sqlx migrations, init the SQLite pool, scan the library if a folder is pre-configured, populate the WebKitGTK profile dir on disk).
• Whatever logic closes the splash fires on a timer (or on an early window event), but the main window isn't ready yet → splash closes before main is visible, or main creation gets stuck.
• Second launch: everything cached, init completes well before the splash close-trigger fires → no race.

Suggested fix direction

Instead of timing-based splash close, have the splash close on an explicit "main-ready" signal — e.g. the React frontend emits a Tauri event after its first paint, the splash window listens and closes itself. That way the timing doesn't matter: the splash always survives at least as long as the main window needs.

Touching points to investigate:

• The splash close path in commands::splash (or wherever the close handler lives — added in feat(ui): splash screen to mask cold-start delay #26).
• The "fix(audio): keep splash close from stopping playback" commit (a4fdaa9) — that fix targeted a related ordering issue.

Fedora / Arch still hang on every launch

On Fedora 44 + CachyOS the symptom doesn't go away on the second launch — splash hangs every time. Possibly the same root cause amplified by WebKitGTK 2.52's slower webview init (per the AppImage memory note for #34), or a second compounded bug.

Will tag this with priority:high and start work on a v1.1.1 hotfix.