Player loads only recorded stems (original+vocals) and greys out stems that exist on disk

[ventuwav]

Before reporting

• I'm on the latest source (main, commit ab95be7) and the issue still happens.
• I searched existing issues and didn't find a duplicate.

What happened?

After separating a track, the studio player shows most stem lanes greyed out and I can't play anything — even though all 6 stems were separated successfully and exist on disk.

The player only loads original + vocals ([player] canplay — 2 stems) and greys out drums, bass, guitar, piano, other. The library lists the track as "· 1 stem". But:

• On disk, all stems are present and valid (79 MB each, correct 7:49 duration):

  jobs/ed6d76809143/stems/
    bass.wav  drums.wav  guitar.wav  original.wav  other.wav  piano.wav  vocals.wav
  

• GET /api/jobs/ed6d76809143 reports all of them:

  { "status": "done",
    "stems": ["original","vocals","drums","bass","guitar","piano","other"] }

• But the player only requests 2 of them over the network:

  GET /api/jobs/ed6d76809143/stems/original.wav → 206
  GET /api/jobs/ed6d76809143/stems/vocals.wav   → 206
  (no request for drums/bass/guitar/piano/other)
  

So the separation is fine; the player just doesn't load the stems that are actually there, which leaves the deck unusable.

Likely root cause (code trace)

The player wires audio from the persisted job state's stem list, not from what's present on disk / returned by the job-detail endpoint:

• catalog.js:656 → wireUpAudio(trackId, track.audioStems, ...)
• track.audioStems comes from catalog.js:367 → audioStems: state.stems || fallbackTrack.audioStems || []
• For this track that persisted state.stems only contains [original, vocals] (hence "1 stem" = stemCount excluding original), so wireUpAudio (player.js:960) only wires 2 lanes and greys the rest.

In other words: when the recorded/selected stem set is narrower than what's on disk, the player trusts the recorded set and ignores stems that exist. Reconciling wireUpAudio's stem list against the job-detail stems (or the on-disk stems/ dir) would fix it.

I believe the narrower recorded set came from a vocals-only / vocal-split separation — htdemucs_6s still wrote all 6 stems to disk, but the job state recorded only the selected one.

Steps to reproduce

1. Import a track (YouTube URL) and separate it with only Vocals selected (or via the vocal-split path).
2. Open the finished track from the library.
3. Observe: the deck loads only original + vocals; the other 5 lanes are greyed and the transport is unusable — despite all 6 *.wav files existing under jobs/<id>/stems/.

Expected: the player loads/plays every stem that exists on disk for the job (or at least the full set the job produced), not only the recorded subset.

Operating system

macOS 26.6.1 (arm64, Apple Silicon)

StemDeck version

0.15.3.dev5+gab95be7ad (source, commit ab95be7)

How did you install it?

From source on macOS: git clone + ./run.sh setup && ./run.sh start (localhost:8000). Compute device: MPS.

Logs

[player] canplay — 2 stems, ctx=running, audios: [original, vocals, drums, bass, guitar, piano, other, undefined:R]

Server also logged repeated WARNING: [youtube] No supported JavaScript runtime could be found during import (separate/minor — bundled yt-dlp runs without a JS runtime), but the separation completed and stems were written regardless.

[thcp]

Thanks for the trace. The file listing, the API response and the network tab
together made this quick to confirm.

The greyed lanes are intentional, and the reason is in how original.wav gets built.

When you pick a subset of stems at import, the pipeline does not keep the raw download as the Original lane. It sums the stems you did not pick. With Vocals selected, original.wav is drums + bass + guitar + piano + other. So Original plus Vocals reconstructs the whole song, with your selected stem isolated next to it.

That is why the player will not load the other five files even though they are on disk. Playing drums.wav alongside Original would play the drums twice, once on its own and once inside Original. The lanes are greyed rather than hiddenbecause the stems really are there, they are just not part of this job's mix.

I reproduced your exact state locally, all seven files present with only Vocals recorded, and the deck does play. Same canplay line reporting 2 stems, same five greyed lanes, and the transport advances normally. If yours genuinely will not play at all, that is a different problem and I would like to see it, so tellme and I will keep digging.

One detail has moved since ab95be7. #479 changed playback to load the individual stems and route the unselected ones into the Original lane internally, so on current main you will see six stem requests instead of two. The visible lanes are the same.

The fair point underneath your report is that the stem selection is fixed at import. Once a track is separated, the only way to get the other lanes back is to import it again, even though the audio is sitting right there. That deserves its own issue rather than being buried in this one, and #479 makes it much cheaper to do than it used to be.

One ask, if you have the time. You are running from source at ab95be7, which predates #479. Could you pull the latest main and open the same track again? I would rather look at your case on the code people are actually running than at my reproduction of it.

If it still looks wrong there, Settings has an Export logs button that zips every log file in one go. Attach that here and I will read through it.

Closing this as working as designed, but do post the logs whenever suits. I will reopen it if there turns out to be more going on than the greying.

Thanks for writing it up so carefully :) The behaviour is intended, but greyed
lanes that do not explain themselves is still a real problem.