The problem
Whether StemDeck deletes finished separations, and after how long, is decided entirely by environment variables: STEMDECK_DESKTOP, STEMDECK_PERSIST_LIBRARY and STEMDECK_JOB_TTL_SECONDS. None of them are visible in the app.
A user cannot find out what their install will do with their library, and cannot change it. The settings panel has controls for track length, playlist limits, export sample rate, compute device and stems location. The one setting that can destroy work is not there.
Why it matters
Two directions, both bad.
Someone who wants their tracks kept has no way to confirm that they will be, short of reading the source or the Unraid template description. The only assurance available is "the variable is probably set".
Someone who wants disk hygiene, which is a legitimate thing to want on a machine that is separating a lot of audio, has to edit a container template or a shell script. On the desktop package there is no supported place to put an environment variable at all.
Who it affects
Everyone, but unevenly. Desktop users get whatever the shell decided. Unraid users get whatever the template author decided, exposed as an advanced variable they have to know to look for. Anyone running the backend directly gets a default they did not choose and cannot see.
Constraints for a fix
- Whatever the control is, "never delete" has to be reachable and unambiguous. A field where
0 means never is ambiguous on a destructive setting: in a box labelled "delete after N days", 0 most naturally reads as delete immediately.
- Retention is the user's policy, not the deployment's, so a stored choice should beat the environment. That is the opposite of
jobs_dir, where the env pin deliberately wins because a mounted volume is not the user's to relocate. The difference needs to be written down where someone will find it.
- Deployments that already tuned
STEMDECK_JOB_TTL_SECONDS should keep their intent rather than silently jumping to a new default.
- Every user-facing string goes through the i18n layer, in all nine tables.
Related: #459 is what happens when this is invisible and defaults to deleting. #462 is why a directly-run backend cannot read the choice even once it exists.
The problem
Whether StemDeck deletes finished separations, and after how long, is decided entirely by environment variables:
STEMDECK_DESKTOP,STEMDECK_PERSIST_LIBRARYandSTEMDECK_JOB_TTL_SECONDS. None of them are visible in the app.A user cannot find out what their install will do with their library, and cannot change it. The settings panel has controls for track length, playlist limits, export sample rate, compute device and stems location. The one setting that can destroy work is not there.
Why it matters
Two directions, both bad.
Someone who wants their tracks kept has no way to confirm that they will be, short of reading the source or the Unraid template description. The only assurance available is "the variable is probably set".
Someone who wants disk hygiene, which is a legitimate thing to want on a machine that is separating a lot of audio, has to edit a container template or a shell script. On the desktop package there is no supported place to put an environment variable at all.
Who it affects
Everyone, but unevenly. Desktop users get whatever the shell decided. Unraid users get whatever the template author decided, exposed as an advanced variable they have to know to look for. Anyone running the backend directly gets a default they did not choose and cannot see.
Constraints for a fix
0means never is ambiguous on a destructive setting: in a box labelled "delete after N days",0most naturally reads as delete immediately.jobs_dir, where the env pin deliberately wins because a mounted volume is not the user's to relocate. The difference needs to be written down where someone will find it.STEMDECK_JOB_TTL_SECONDSshould keep their intent rather than silently jumping to a new default.Related: #459 is what happens when this is invisible and defaults to deleting. #462 is why a directly-run backend cannot read the choice even once it exists.