[Bug]: A track that fails to load tells the user nothing #359

What happens

When every stem fails to load, playback is disabled like this:

console.warn("[player] audio engine had no usable stems; playback disabled");
teardownMetronome();
updateMetronomeAvailability(null, "Playback unavailable for this track");

A console.warn in a WebView with no devtools in release builds, and a tooltip on the metronome button. What the user sees is a track that loaded, shows its key, BPM and duration, and then simply does nothing: empty waveform lanes, 0:00 / 0:00, a play button that does not play. No error, no hint, nothing to search for.

The individual failures are equally quiet -- console.warn("[chunked] header fetch failed:", e) and the equivalent in the full-decode engine.

Why it matters

This is the difference between a bug report we can act on and one we cannot. #343 took a screenshot, a reading of the transport clock, and a walk through the engine source to get to a hypothesis, and it still is not confirmed. The reporter had no way to know anything had gone wrong beyond "it does not work", and no way to tell us which part.

They also concluded it was a GPU or driver problem, which is understandable from the symptoms and sent the investigation in the wrong direction.

Expected

When a track cannot be played, say so where the user is looking -- the same treatment an import failure gets via showError. It should name what failed (audio could not be loaded for this track) and be specific enough to search for or paste into an issue.

The per-stem failures should be surfaceable too. They do not all need to be in the user's face, but a diagnostic that only exists in a console nobody can open is not a diagnostic.

Related

• [Bug]: WAV header parse gives up after 1 KB, silently disabling playback #358 -- one concrete way stems fail to load
• [Bug]: Waveforms and playback do not work on Linux version (hardware dependent?) #343 -- the report this came from