[Bug]: Stuck First Launch

Before reporting

I'm on the latest release and the issue still happens.
I searched existing issues and didn't find a duplicate.

What happened?

Just try in Linux and Mac, at first launch Mac Arm show progress, but in Linux (I use Debian with NVIDIA RTX 5070Ti) seem stuck without any progress shown. All deps writen in docs already installed, also no log in console.

Steps to reproduce

Open stemdeck
Just wait for stuck

Operating system

Linux

StemDeck version

0.15.2

How did you install it?

Linux tar.gz

Logs / screenshots

No response

Hi,

Could you please try the pre release? https://github.com/stemdeckapp/stemdeck/releases/tag/v0.16.1

@thcp

Hi @thcp,

The issue still happen.

@raniaamina

Hey @raniaamina , just to say that it's not forgotten :)

Could you also please provide your gpu series and Linux distribution ?

I mentioned in first post :")
I use Debian Sid with NVIDIA RTX 5070Ti.
Just test running via source code, this series need latest torch cuda130 to work well. Not sure this caused by this different lib version or not, since the apps just stuck with no log that i can check.

@raniaamina

@raniaamina my bad, I totally got distracted. will look into that now.

fix(gpu): offer Blackwell a wheel that matches its driver, and try mo…

@raniaamina

@raniaamina

I found two possible problems and a disclaimer that I used AI with this comment since I'm really sleepy, but in the essence, 80% was made by me so here it goes:

The app was hanging, not just failing. The GPU check runs a real CUDA kernel launch to make sure the installed PyTorch actually works on your card. That call had no timeout, so when the driver and the wheel disagree it blocks forever inside the driver. Setup just stopped, which is exactly the "no progress, no logs" you saw.

Blackwell only ever got one wheel. The code handed every RTX 50-series card cu128 no matter what driver was present. Your 5070 Ti on a CUDA 13 driver was never offered anything else, so if that pairing didn't work there was nowhere to go. Related: a CUDA 13 driver was falling through to a cu124 wheel, two major versions behind.

So now the app tries cu130 (torch 2.11.0) first on a CUDA 13 driver, falls back to cu128 (torch 2.8.0) if that fails, and only drops to CPU after both fail. Every attempt gets written to setup.log with the tag and torch version.

If you're able to test from source again, the branch is fix/502-stuck-first-launch:

git fetch origin
git checkout fix/502-stuck-first-launch
bash scripts/linux/make-portable.sh

That needs uv, cargo, node, npm, tar and sha256sum on PATH, and produces a bundle under dist/.

To make sure it re-runs GPU detection from scratch rather than reusing an earlier result:

rm -rf ~/.local/share/stemdeck/logs/setup.log

Then whatever happens — working or not — could you send ~/.local/share/stemdeck/logs/setup.log? It'll now show which step it reached and which wheels it tried, something like:

[...] step: gpu-setup
[...] trying CUDA wheel cu130 (torch 2.11.0)
[...] cu130 verified

Two things I want to be upfront about. I don't have a Blackwell card or a Linux machine, so this is reasoned from the PyTorch index and your report rather than tested on the hardware — you're the only one who can confirm it. And if cu130 also fails to verify, the log will say so, and we'll at least know it's a torch version problem rather than guesswork.

The work is in #569 if you want to look.

Two notes for you, not for the comment: I mentioned ~/.local/share/stemdeck as the data dir — that's the XDG_DATA_HOME fallback, so it's right unless they've set that variable. And deleting setup.log isn't strictly needed, but a clean log makes their report far easier to read.

fix(gpu): keep Blackwell on cu128 rather than the wheel that matches …

I tried twice, first run this bash scripts/linux/make-portable.sh and the second CPU_ONLY=0 ./scripts/linux/make-portable.sh

For first try, it run and open but only with CPU no GPU log at all.

The second, stuck and here is the log:
setup.log

I've waiting about 15 minutes with no result.

I tried to open again and watch the log; found this error

[1788515606] [stemdeck] CUDA verify failed. stderr:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/run/media/sherlock/zeroDrive/Labs/stemdeck-fix/dist/StemDeck-Linux-x64/python/lib/python3.12/site-packages/torch/__init__.py", line 416, in <module>
    from torch._C import *  # noqa: F403
    ^^^^^^^^^^^^^^^^^^^^^^
ImportError: libcudnn.so.9: cannot open shared object file: No such file or directory

fix(setup): show what the CUDA install is doing instead of a silent s…

fix(setup): bound the GPU probe and record which step is running

fix(gpu): offer Blackwell a wheel that matches its driver, and try mo…

fix(gpu): keep Blackwell on cu128 rather than the wheel that matches …

Thanks for testing twice and for posting the log. Both runs told me something I
could not have found otherwise, and the libcudnn.so.9 line in particular.

Two things have changed on the branch since you tried it.

The install was silent, and that was the real problem

You waited fifteen minutes and saw nothing. That was the correct read of what was
on screen, because there was genuinely nothing there. The CUDA install wrote its
output to nowhere: no lines to setup.log, no progress on the setup screen, for
up to twenty minutes per pass and two passes on Linux. From where you sat that is
identical to the hang you reported in the first place.

It is not a small download either. The cu128 torch wheel for Linux is 847 MB and
nvidia-cublas on its own is 566 MB, before another dozen nvidia-* packages.

That silence is also what produced your second error. The install runs in two
passes: the first puts CUDA torch in place, the second installs the CUDA runtime
that torch loads at import. Closing the app between them leaves torch unable to
import at all, which is exactly the libcudnn.so.9 you saw. Nothing you did
wrong. The app gave you no way to tell a long download from a dead one.

Now it streams. You will see the file being downloaded and its byte count, both
on the setup screen and in setup.log.

One correction to what I told you earlier

I said it would try cu130 first on your CUDA 13 driver. That turned out to be
wrong and I dropped it. Every cu130 wheel carries torchaudio 2.9 or newer, and
torchaudio removed its soundfile backend in 2.9: save() there goes through
torchcodec, which StemDeck does not ship. demucs writes every stem with
ta.save(), so a cu130 install would have verified happily on the GPU and then
failed at separation time, which is a worse place to find out.

So the log will say cu128, and that is intended, not the old behaviour. CUDA is
backward compatible, so a cu12x build runs on your CUDA 13 driver.

If you have time to try again

git fetch origin fix/502-stuck-first-launch
git checkout -B fix/502-stuck-first-launch origin/fix/502-stuck-first-launch
CPU_ONLY=0 bash scripts/linux/make-portable.sh

I rebased the branch, so the -B matters: a plain checkout of an older copy
would not move.

Then clear the log so what you send is only this run:

rm -f ~/.local/share/stemdeck/logs/setup.log

And this time, please let it run even if it looks slow. It should now be saying
what it is doing. If it goes quiet for several minutes with no new line, that
itself is the useful result and worth telling me.

Whatever happens, ~/.local/share/stemdeck/logs/setup.log is what I would like
to see. It will now name every wheel tried and every file downloaded.

What I still cannot promise

I have no Blackwell card and no Linux machine here, so I cannot tell you whether
cu128 will actually verify on a 5070 Ti under a CUDA 13 driver. What I can tell
you is that if it does not, you will get a clear line saying so and a working
CPU install, instead of an app that stops with nothing on screen. If the log
says the wheel installed but did not verify, that is a torch version problem and
its own piece of work, and at least we will know.

Thanks again for the patience on this one.

Bound the GPU probe, show what the CUDA install is doing, and make th…

Correction to my last comment: the branch is gone. It merged, so build from
main instead.

git checkout main
git pull
CPU_ONLY=0 bash scripts/linux/make-portable.sh

Then clear the log so what you send is only this run:

rm -f ~/.local/share/stemdeck/logs/setup.log

I have deliberately left this issue open. Three things merged that were worth
having on their own, and none of them is the answer to your problem:

The CUDA install no longer runs silently. You will see the file being
downloaded and its byte count, on screen and in setup.log.
A subprocess timeout that was not actually bounding anything. When the child
had children of its own, the "give up after N seconds" waited for the
grandchild instead. Against a 2 second deadline it waited 300.
A dead function that was failing CI on the branch.

What none of that settles is whether cu128 verifies on a 5070 Ti under a CUDA 13
driver. Nobody has confirmed that, which is why this stays open rather than
closing with the merge.

So the run I am asking for is the same one, and please let it run this time even
if it looks slow. It should now be saying what it is doing. If it goes quiet for
several minutes with no new line, that is itself the useful result and worth
telling me.

Either way, ~/.local/share/stemdeck/logs/setup.log is what I would like to
see. It will name every wheel tried and every file downloaded, so if cu128
installs and then fails to verify, we will know that is a torch version problem
rather than guessing at it.

Thanks for the patience. Both of your earlier reports moved this along more than
they probably felt like at the time.

Let me try for next few days, and give feedback again here

It works!
It need more times as expected with my connection (around 1Gbps/s) but it works after i tried 2 times. At first try, it still stuck at middle proses, after i killed the process and restart apps it seem works. I also check the process when separating is detected in nvidia-smi/nvitop process.

But i found some error in in log, i attached all logs here.

setup.log
stemdeck.log

This is good news, and your logs told me more than the working run did. Thanks for attaching them.

Two things are in there, and neither is what the working run suggested.

The first run did not hang. It was downloading, at about 0.77 MB/s, and I killed it at twenty minutes. The CUDA runtime for Linux is around 3 GB, and the cudnn wheel alone had been going for fifteen of those minutes when the cap hit. Your second run got the same wheel in three minutes on a faster connection, and finished with roughly three minutes to spare against the same cap. So the second run did not fix anything. Your network was kinder. Anyone on your first run's speed never gets there, which makes that cap the bug, not your machine.

A download that is visibly moving should not be given up on. I have replaced the fixed deadline with one that only fires when nothing has arrived for a while, with a long backstop behind it. That is the pattern the separation pipeline already uses, and the setup path should have been using it too.

The second thing is why your log says beat_this and vocal_split failed 25 seconds in. Those two model files are on your disk but truncated. Both libraries check only that the file exists, never that it loads, so they will keep failing on every run from here. In practice that means your beat grid has been quietly falling back to librosa instead of the neural model this whole time, and nothing told you. That is its own bug and I have fixed it properly, so a bad file now gets discarded and refetched.

You can get those two working again today without waiting for a release:

rm -f ~/.local/share/stemdeck/models/torch/hub/checkpoints/beat_this-final0.ckpt
rm -rf ~/.local/share/stemdeck/models/audio-separator

Before you delete them, if you can send me the output of ls -l on both of those directories, that would help. A file well under 80 MB means the connection cut it short. A .partial sitting next to it means a process was stopped mid-write. It is the one thing I cannot work out from here, and it decides whether there is a third bug.

One good answer came out of all this. cu128 verifies on a CUDA 13 driver, which is the question this issue was held open for. I have since confirmed the other half of it too, on an RTX 3080, which is Ampere rather than Blackwell, under a 13.4 driver. Kernel launch and synchronize both come back clean. So that branch is sound on both card generations and I can close that part out.

Thanks for sticking with this. The two runs side by side are what made the cap obvious.

fix(setup): seven review findings, two of which broke the change itself

~/.local/share/stemdeck
ls -ls models/*
models/audio-separator:
total 1084
  28 -rw-rw-r-- 1 sherlock sherlock   28267 Sep  8 17:38 download_checks.json
  16 -rw-rw-r-- 1 sherlock sherlock   15358 Sep  8 17:56 mdx_model_data.json
1032 -rw-rw-r-- 1 sherlock sherlock 1056768 Sep  8 17:38 UVR_MDXNET_KARA_2.onnx
   8 -rw-rw-r-- 1 sherlock sherlock    4380 Sep  8 17:56 vr_model_data.json

~/.local/share/stemdeck
ls -ls models/*/*/*
total 60664
53712 -rw-rw-r-- 1 sherlock sherlock 54996327 Sep  8 17:19 5c90dfd2-34c22ccb.th
 6952 -rw-rw-r-- 1 sherlock sherlock  7110852 Sep  8 17:37 beat_this-final0.ckpt

setup.log
stemdeck.log

It was downloading, at about 0.77 MB/s

Seem strange, my connection speed is almost 1Gb/s, but somehow droped when pulling deps.
Basicly the the core problem in this issue is solved, but as found in logs, it seem still something not run as expected, just it.
Thanks btw, for giving attention for this issue.

Keep audio alive in a hidden tab, and stop trusting downloads that ne…

@raniaamina

@raniaamina That log was worth more than a working run again. Thank you.

On the speed: a gigabit line dropping while pulling several GB from pypi.nvidia.com is exactly the case the old cap could not tell apart from a hang. It only ever looked at the clock, so a slow stretch and a dead process were the same thing to it. It now watches for silence instead, so a transfer that slows down is left alone and only one that stops actually gets stopped.

The nms error is a separate bug, and a real one. It is not about your machine.

torchvision ships compiled operators built against one specific version of torch. Put it beside a different torch and those operators are never registered, so nothing fails at install time and instead the first thing to call one falls over. Here that is the karaoke split: audio-separator loads onnx2torch, which needs torchvision, which needs nms. Demucs never touches torchvision, which is why separation kept working and only the split broke.

The cause is on my side. The CUDA install swaps torch and torchaudio and deliberately skips dependency resolution, which keeps it fast. torchvision was simply never named in that list, so it stayed on the version that belongs to the older torch. That only matters on the cu128 line, because that is the only one that moves torch, and cu128 is what a CUDA 13 driver now gets. So the change that got your install working is what put you in front of this one. Worth saying out loud rather than leaving in a commit.

Fixed in #615: both install paths now pin a torchvision that matches the torch they install, and the two versions live next to each other so they cannot drift apart quietly.

I cannot reproduce this one locally, since it needs a real cu128 install on a CUDA 13 machine. I have checked the versions exist and the reasoning against your traceback, but you are the person who can tell me whether the split actually works. If you are willing to try once it lands, that would close it properly.

The original question this issue was opened for is answered, by the way. cu128 verifies on a CUDA 13 driver, on Blackwell from your run and on Ampere from a 3080 here, kernel launch and synchronize both clean.

Your ls answered it, and more cleanly than I expected. Thank you for running it.

The files were cut short by the connection, not by anything being killed mid-write. Two things say so. There is no .partial anywhere, and both bad files carry their final names at a fraction of their real size, which is what happens when the body ends early and the download is moved into place anyway.

The numbers, against a known good copy here:

file	yours	correct
`beat_this-final0.ckpt`	7,110,852	81,058,141	8.8% of it
`UVR_MDXNET_KARA_2.onnx`	1,056,768	far larger	why the MD5 lookup found nothing
`5c90dfd2-34c22ccb.th`	54,996,327	54,996,327	byte for byte identical, intact

That last row is the useful one. The Demucs checkpoint came down complete in the same session, over the same connection, while the other two were cut. So this was not a bad network hour taking everything with it. It dropped some transfers and not others, and nothing checked afterwards which was which. That is the whole bug, and your directory listing is the clearest demonstration of it I could have asked for.

Four things are now fixed on main because of this issue:

The install cap that killed your first run. It now gives up on silence rather than on elapsed time, so a transfer that slows down is left alone.
Model files are no longer trusted just because they exist. A checkpoint that fails to load is discarded and fetched again, once.
The karaoke split's torchvision::nms failure, which was a version mismatch on my side: the CUDA install replaced torch and left torchvision on the version belonging to the older one.
Setup now says which models did not download, instead of reporting a clean run.

You can get the two broken models back today without waiting, since deleting them is exactly what the new code does by itself:

rm -f ~/.local/share/stemdeck/models/torch/hub/checkpoints/beat_this-final0.ckpt
rm -rf ~/.local/share/stemdeck/models/audio-separator

Your beat grid has been falling back to librosa on every job since that file landed, so this is worth doing whether or not you try the next build.

I am leaving this open until you have had a chance to confirm. The parts I could verify here are verified, but the karaoke split fix in particular needs a real cu128 install on a CUDA 13 machine, which is yours and not mine. If it works after the next release, say so and I will close it.

And the cu128 question this issue was originally held for is settled: it verifies on your Blackwell card and on an Ampere 3080 here, kernel launch and synchronize both clean.

@raniaamina

Hey @raniaamina , I'm closing this one to ship 0.17.1 this weekend, please let me know further updates so I can ship on the next release :)

Thanks for giving responses to this report!

Install a CUDA wheel that exists on a pre-12.4 driver (#650)

Navigation Menu

Repository navigation

[Bug]: Stuck First Launch #502

Before reporting

What happened?

Steps to reproduce

Operating system

StemDeck version

How did you install it?

Logs / screenshots

2 remaining items

The install was silent, and that was the real problem

One correction to what I told you earlier

If you have time to try again

What I still cannot promise

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Stuck First Launch #502

Description

Before reporting

What happened?

Steps to reproduce

Operating system

StemDeck version

How did you install it?

Logs / screenshots

Activity

thcp commented on Sep 1, 2026

raniaamina commented on Sep 1, 2026

thcp commented on Sep 3, 2026

raniaamina commented on Sep 3, 2026

thcp commented on Sep 3, 2026

thcp commented on Sep 3, 2026

raniaamina commented on Sep 4, 2026

2 remaining items

thcp commented on Sep 6, 2026

The install was silent, and that was the real problem

One correction to what I told you earlier

If you have time to try again

What I still cannot promise

thcp commented on Sep 6, 2026

raniaamina commented on Sep 7, 2026

raniaamina commented on Sep 8, 2026

thcp commented on Sep 9, 2026

raniaamina commented on Sep 9, 2026

thcp commented on Sep 9, 2026

thcp commented on Sep 9, 2026

thcp commented on Sep 13, 2026

raniaamina commented on Sep 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions