You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Several issues with my portable package #399
I'm on the latest release and the issue still happens.
I searched existing issues and didn't find a duplicate.
What happened?
Thanks for the great app, but I am unable to use it because of these issues:
On first run, I saw a notification for v0.11.2 having downloaded v0.11.1 It downloaded the portable package, as that was the version I had, copied all files over, but then found the notification remained. I checked the version and it is indeed still 0.11.1. Although the last_version file states 0.11.2
After waiting for FFMpeg to download, despite StemDeck reporting it is supposed to be installed, it is NOT in the portable folder.
I specifically downloaded the zip version and only use portable apps. I have noticed that this portable version is not saving anything into its own folder, but is instead saving to system folders. User\Docs and AppData\Local, which is where I found the FFMpeg download. Portable means saving all files in the apps directory, which I assume is why there are empty folders there so assume this is either a bug, or I missed something?
this is stated in the Readme file: Demucs model weights are downloaded by the backend on first use into data/models/. But nothing is downloaded.
The app appears to be using the registry too, which also breaks portability.
I downloaded the latest version, v0.11.2 just to confirm behaviour has not changed. I deleted the data before reinstalling to be sure, same thing happens. It auto-creates all files and folders on system drive instead of in the apps Data folder like the Readme states.
Few suggestions:
Add a simple portable.txt file to the portable zip package, when read, it automatically forces the app to use portable relative paths and saves everything in the Root\data folder.
Embed python into the exe, easier for users to have a single exe.
Close/minimise the cmd window, users dont wanna see that! ;) Its useful for debugging, but not for users.
The app looks amazing and I can't wait to try it!
Steps to reproduce
Download the Windows.zip package, extract and run, thats all I did.
Hey, thank you so much for such a detailed writeup, reports like this make it way easier to actually fix things properly instead of guessing. I went through each point against the code, here's what I found:
FFmpeg downloading to AppData instead of the portable folder: you're right. It's currently hardcoded to %LOCALAPPDATA%\StemDeck\ffmpeg no matter where the zip is extracted.
Demucs model weights not showing up under data/models/: same cause as the FFmpeg one, not a separate bug. The model cache is pointed at AppData too, so it is downloading, just not into the folder the README leads you to expect. Sorry for the confusion there.
The zip writing to %LOCALAPPDATA% / ~\Documents instead of its own folder: also right. Runtime, FFmpeg, Demucs models, config, and logs go to %LOCALAPPDATA%\StemDeck; job/library data goes to ~\Documents\StemDeck. Neither is relative to the extracted zip today, so it's fair to say "portable" doesn't fully hold yet on Windows.
Registry usage: good news here, this one isn't happening. StemDeck doesn't touch the Windows Registry at runtime anywhere in the app. The only place winreg shows up at all is as a transitive dependency of tauri-build, used purely to embed the .ico/version resource into the .exe when it's compiled on the build machine. It never runs, and never touches the registry, on your machine.
Update downloading but the app still showing 0.11.1: there's actually no in-app auto-updater yet, the "Download" button on that notification just opens the GitHub release page in your browser, nothing installs itself. What you ran into was last_version.txt in that shared AppData folder getting overwritten by a separately-extracted copy, a side effect of the non-portability above rather than a broken update. Makes sense you'd read it as one, though. Digging into this also surfaced a related question worth its own thread, whether non-release notifications should clear on app restart, tracked separately in Notification persistence: only release notifications should survive a reboot #401.
Here's the plan: an upcoming release will ship a portable.txt marker inside future Windows zips by default (exactly what you suggested), so a fresh extract keeps FFmpeg, Demucs models, config, and logs in a data/ folder right next to StemDeck.exe instead of AppData. Your job/library data will stay right where it is today (~/Documents/StemDeck by default) rather than also moving next to the exe, that folder sits right beside the app binary, and I'd rather not risk your whole library if someone deletes or overwrites the portable folder thinking it's disposable. It's already movable anytime from Settings → StemData location, including into the portable folder yourself if you'd genuinely prefer it there.
Thanks again for taking the time to write this up so thoroughly, really appreciate it. I'll circle back here once it ships!
Amazing, thank you so much! One thing though, I have found registry entries, though I'm not sure if these are normal for portable apps, but there are many entries there. So maybe worth looking into a bit more? Much appreciated. ;)
Also, note in my first point that I downloaded the update and copied the files over but the version remained at 0.11.1, i think you may have missed that part? Because even after updating the app itself stated 0.11.1 still.
Glad descriptions helped! I've learnt over the years that it helps to explain properly, though sometimes I completely cock that up too! Lol
Hey thanks for the update, it has worked for th emost part. One folder is still not portable though, the Documents\StemDeck one is still being created on startup. This contains a user-data.json file and an empty folder. Would you mind making this portable too please. Thanks.
EDIT: I noticed theres a setting for this location but all efforts to change it are blocked. I then tested a track and it was separated. The data is stored in the C docs folder. I closed StemDeck, moved the data to the portable folder, restarted, and the jobs folder and the user-dat.json file are ignored. It is still hardcoded to the system folder. I can even see the name of the path I changed the logs to in the settings file, but the settings window still uses the system folder.
Activity
thcp commentedon Aug 20, 2026
Hey, thank you so much for such a detailed writeup, reports like this make it way easier to actually fix things properly instead of guessing. I went through each point against the code, here's what I found:
%LOCALAPPDATA%\StemDeck\ffmpegno matter where the zip is extracted.data/models/: same cause as the FFmpeg one, not a separate bug. The model cache is pointed at AppData too, so it is downloading, just not into the folder the README leads you to expect. Sorry for the confusion there.%LOCALAPPDATA%/~\Documentsinstead of its own folder: also right. Runtime, FFmpeg, Demucs models, config, and logs go to%LOCALAPPDATA%\StemDeck; job/library data goes to~\Documents\StemDeck. Neither is relative to the extracted zip today, so it's fair to say "portable" doesn't fully hold yet on Windows.winregshows up at all is as a transitive dependency oftauri-build, used purely to embed the.ico/version resource into the.exewhen it's compiled on the build machine. It never runs, and never touches the registry, on your machine.last_version.txtin that shared AppData folder getting overwritten by a separately-extracted copy, a side effect of the non-portability above rather than a broken update. Makes sense you'd read it as one, though. Digging into this also surfaced a related question worth its own thread, whether non-release notifications should clear on app restart, tracked separately in Notification persistence: only release notifications should survive a reboot #401.Here's the plan: an upcoming release will ship a
portable.txtmarker inside future Windows zips by default (exactly what you suggested), so a fresh extract keeps FFmpeg, Demucs models, config, and logs in adata/folder right next toStemDeck.exeinstead of AppData. Your job/library data will stay right where it is today (~/Documents/StemDeckby default) rather than also moving next to the exe, that folder sits right beside the app binary, and I'd rather not risk your whole library if someone deletes or overwrites the portable folder thinking it's disposable. It's already movable anytime from Settings → StemData location, including into the portable folder yourself if you'd genuinely prefer it there.Thanks again for taking the time to write this up so thoroughly, really appreciate it. I'll circle back here once it ships!
Portable Windows data dir + auto-clear resolved failure notifications (…
sl2365 commentedon Aug 21, 2026
Amazing, thank you so much! One thing though, I have found registry entries, though I'm not sure if these are normal for portable apps, but there are many entries there. So maybe worth looking into a bit more? Much appreciated. ;)
Also, note in my first point that I downloaded the update and copied the files over but the version remained at 0.11.1, i think you may have missed that part? Because even after updating the app itself stated 0.11.1 still.
Glad descriptions helped! I've learnt over the years that it helps to explain properly, though sometimes I completely cock that up too! Lol
sl2365 commentedon Aug 21, 2026
Hey thanks for the update, it has worked for th emost part. One folder is still not portable though, the Documents\StemDeck one is still being created on startup. This contains a user-data.json file and an empty folder. Would you mind making this portable too please. Thanks.
EDIT: I noticed theres a setting for this location but all efforts to change it are blocked. I then tested a track and it was separated. The data is stored in the C docs folder. I closed StemDeck, moved the data to the portable folder, restarted, and the jobs folder and the user-dat.json file are ignored. It is still hardcoded to the system folder. I can even see the name of the path I changed the logs to in the settings file, but the settings window still uses the system folder.
feat: default new portable installs' jobs folder inside the package (#…
feat: default new portable installs' jobs folder inside the package