[Bug]: Unable to export stems again after exporting stems without restarting the program #335

Activity

1. MetalMan1245

   added

   bugSomething isn't workingSomething isn't working

   on Aug 8, 2026
2. thcp

   self-assigned this

   on Aug 8, 2026
3. thcp commented on Aug 8, 2026

   

   thcp

   on Aug 8, 2026

   Collaborator

   More actions

   Hey @MetalMan1245 will look into that before this Monday, I actually wrapped up pre release alpha 16 and will go to bed now :) thanks for the report!
4. thcp

   added a commit that references this issue on Aug 9, 2026

   fix(export): track real export completion instead of a fixed timer

   ...

   aa4f847
5. thcp

   closed this as completedin #337on Aug 9, 2026
6. thcp

   added a commit that references this issue on Aug 9, 2026

   fix(export): re-enable Export All Stems after an export (#337)

   ...

   This issue will close once commit b610275 is merged into the 'main' branch.

   b610275
7. thcp commented on Aug 9, 2026

   

   thcp

   on Aug 9, 2026

   Collaborator

   More actions

   Fixed in #337, merged to main as b610275.

   Thanks for this one, @MetalMan1245 - your repro steps were exact and that made it quick to find.

   What was wrong: the export menu disables its three rows while an export runs, then re-enables them when it finishes. It re-enabled "Export Mix" and "Export Current Region" but never "Export All Stems", so that row stayed greyed out and unclickable. The menu is part of the app shell rather than the song view, which is why it stayed dead for every song and only a restart cleared it.

   Slightly worse than you described: any export triggers it, not just the zip. Exporting a mix once was enough to kill the stems row for the rest of the session.

   Why we missed it: it only happens in the desktop app. In a browser the download is started by a hidden link whose click closes the menu a moment before the disabling runs, so the bug never appears. The desktop build saves through a native dialog instead, no click, menu still open, rows get disabled. So the tar.gz and .exe builds were affected and nothing in our test setup ever hit that path. I have filed #339 to close that gap properly.

   While in there I fixed three more problems in the same code:

   • "Exporting..." was shown for a download that had not actually started
   • The button reported success after a fixed 1.2 seconds no matter how long the export really took, so on a large zip it said done while the file was still being written, and a failed export looked identical to a successful one. It now waits for the real thing and tells you when a save fails.
   • A failed export offered a "Try again" button that sent you to the URL import box, which does nothing for an export. It is a plain Dismiss now.

   When you can test it: it is not in alpha 16, that build predates the fix. It will be in the next pre-release, and I will reply here when that is out.

   If you want to keep an eye on releases: @stemdeckapp.
8. thcp commented on Aug 9, 2026

   

   thcp

   on Aug 9, 2026

   Collaborator

   More actions

   Alpha 17 is out, and it has the fix: https://github.com/stemdeckapp/stemdeck/releases/tag/v0.8.0-alpha.17

   @MetalMan1245 you should be able to test it now. Grab the Linux .tar.gz for your hardware, same as before.

   What to check, the exact flow from your report:

   1. Split stems for a track
   2. Export the stems zip
   3. Export again without restarting

   "Export All Stems" should stay clickable this time, for that track and for every other one you switch to.

   Worth trying too, since these were all part of the same broken code:

   • Export a mix, then open the export menu again. Any export used to poison the stems row, not just the zip, so this was the other way to hit your bug.
   • Export a large zip. The button used to say it was done after 1.2 seconds regardless, while the file was still being written. It now waits for the real thing.
   • If a save fails, you now get told. Previously a failed export looked exactly like a successful one, which is part of why this went unnoticed for so long.

   Your report also turned out to be desktop-only. In a browser the bug is invisible, which is why it survived Alpha 15 and 16 with nobody catching it. I have opened #339 to add the frontend test coverage that would have caught it.

   Alpha 17 also includes #336, so your stem filenames are fixed in the same build.

   Let me know how it goes, and thanks again for the two clear reports.
9. thcp

   added a commit that references this issue on Aug 12, 2026

   test(frontend): add browser tests, starting with the export menu (#365)

   ...

   1e1cf0b