The problem
The Song structure toggle is a saved preference, and it should not be.
Switch it on once and it stays on: for the next import, for every import after
that, and for every session until someone remembers to switch it off. It is
stored server-side, so it also stays on across a restart and for anyone else
pointed at the same StemDeck.
That is the wrong shape for what it does. The pass it enables is minutes of CPU
per import. A setting that quietly keeps spending that, long after the song the
user turned it on for, is a cost nobody chose.
It should be a choice about the next import: on because the user just asked, off
again once that song is open.
The part that makes this more than a UI change
The runner reads the setting when it reaches the sections stage, which is the
last thing the pipeline does. There is a comment explaining why:
The setting is read here, per job, rather than captured at import, so
turning the toggle off applies to the next job without a restart.
That is exactly right for a preference and exactly wrong for a per-import
choice. If the toggle clears itself when the user opens another song, and the
stage runs minutes after submit, then a user who switches it on, starts an
import, and browses to another track while waiting loses the pass they asked
and waited for. Silently: the job completes, with no sections and no
explanation.
So whatever makes the toggle transient has to move the decision to the moment
the user makes it, not the moment the pipeline gets around to it.
Constraints
- Turning the button off is not enough on its own. The server setting is what
the runner reads, so the two have to move together or the next import still
pays for a pass nobody asked for.
- Jobs are created in three places: a URL submit, a file upload, and a playlist
import. A playlist import creates many jobs at once and they should agree.
The problem
The Song structure toggle is a saved preference, and it should not be.
Switch it on once and it stays on: for the next import, for every import after
that, and for every session until someone remembers to switch it off. It is
stored server-side, so it also stays on across a restart and for anyone else
pointed at the same StemDeck.
That is the wrong shape for what it does. The pass it enables is minutes of CPU
per import. A setting that quietly keeps spending that, long after the song the
user turned it on for, is a cost nobody chose.
It should be a choice about the next import: on because the user just asked, off
again once that song is open.
The part that makes this more than a UI change
The runner reads the setting when it reaches the sections stage, which is the
last thing the pipeline does. There is a comment explaining why:
That is exactly right for a preference and exactly wrong for a per-import
choice. If the toggle clears itself when the user opens another song, and the
stage runs minutes after submit, then a user who switches it on, starts an
import, and browses to another track while waiting loses the pass they asked
and waited for. Silently: the job completes, with no sections and no
explanation.
So whatever makes the toggle transient has to move the decision to the moment
the user makes it, not the moment the pipeline gets around to it.
Constraints
the runner reads, so the two have to move together or the next import still
pays for a pass nobody asked for.
import. A playlist import creates many jobs at once and they should agree.