Loss of function and lingering after uninstalling

[DefactoCasual]

The GUI shows nothing is connected and nothing functions. Every time i change a setting I keep getting the "USB device permissions not applied" popup. This popup is also still there every time i boot my PC, so it seems my previous issue wasn't fixed either.

I notice that ASM also stays open when looking in system monitor, even when closing the program (pressing exit on the icon on the task bar).

Many attempts at uninstalling fully also seem to fail now as no matter what i do, the program still lingers after reboot, even when deleted through the DNF app center and deleting .desktop files/files associated with ASM (that i could find).

Can i get some help on removing ALL files related to ASM so i can do an actual fresh install. The command for a fresh install that i was shown when i had "multiple installs" never actually worked and i had to manually hunt some files down.

[DefactoCasual]

My headset still works without ASM, but losing Sonar functionality and being stuck with the settings that are currently applied (mic side tone for example) is quite annoying.

[loteran]

You did nothing wrong, and there is nothing left for you to hunt down by hand. The uninstaller was blind to both of the installs you had. That is a bug in this project, and you have now hit it twice — in July you solved it yourself by finding those files in ~/.local/lib/python3.14/site-packages, which is more than the tool I gave you managed to do.

What was actually wrong

I went through the script against your case. Two separate holes:

1. A pip install --user copy was detected and then ignored. The script printed the stray asm-daemon binaries as a note and moved on — it never touched ~/.local/lib/python3.14/site-packages/arctis_sound_manager. And when that copy was the only thing left, which is exactly where you were after removing the package through DNF, it reported:

[ok] No Arctis Sound Manager installation detected — nothing to do.

…three lines after printing the file that was still there. So "no matter what i do, the program still lingers after reboot" was the literal truth: the uninstaller was telling you there was nothing to uninstall while ASM kept starting at every boot.

That copy also explains the rest of what you are seeing. Python looks in ~/.local before the system location, so an old copy there wins over the packaged one no matter what DNF does — which is why the GUI detects nothing and why the permissions popup keeps coming back even though your udev rules are fine.

2. On Nobara, nothing was detected at all. The script only ever looked for a package named arctis-sound-manager. The one you have comes from Terra and is named python3-arctis-sound-manager, so as far as the uninstaller was concerned you had nothing installed.

Both are fixed. A removal that fails now says so, too, instead of printing "removed" regardless — that false reassurance is part of what kept you looking in the wrong place.

One command, and it works right now

I have put the fixed uninstaller in place ahead of the release, so you do not
have to wait for it or do any of this by hand:

curl -fsSL https://raw.githubusercontent.com/loteran/Arctis-Sound-Manager/main/scripts/uninstall.sh | bash -s -- --all --purge

It finds both installs — the Terra package and the ~/.local copy — asks before
each removal, and clears the settings and PipeWire configuration too, so what
follows is a genuinely fresh start. I tested it against your exact situation
first: a ~/.local copy with the package already gone, which is the case that
used to print "nothing to do".

Reboot once it finishes, then reinstall:

sudo dnf copr enable loteran/arctis-sound-manager
sudo dnf install arctis-sound-manager

That is the package I build and can actually fix. Do not install with pip
afterwards — the copy in ~/.local is what caused all of this, and it will
quietly take over again.

What that command does, if you would rather do it yourself

Run them one at a time; nothing here touches anything but ASM.

Stop it first, so nothing is running while you delete it:

systemctl --user stop arctis-manager.service arctis-video-router.service arctis-stream-guard.service
systemctl --user disable arctis-manager.service arctis-video-router.service arctis-stream-guard.service

See what you actually have — worth pasting back here if anything below misbehaves:

rpm -q arctis-sound-manager python3-arctis-sound-manager
ls -d ~/.local/lib/python*/site-packages/arctis_sound_manager 2>/dev/null
command -v -a asm-daemon

Remove the packages (one of the two will say "not installed", that is fine):

sudo dnf remove arctis-sound-manager
sudo dnf remove python3-arctis-sound-manager

Remove the ~/.local copy — the one that survived everything:

rm -rf ~/.local/lib/python*/site-packages/arctis_sound_manager
rm -rf ~/.local/lib/python*/site-packages/arctis_sound_manager-*.dist-info
rm -f ~/.local/bin/asm-daemon ~/.local/bin/asm-cli ~/.local/bin/asm-gui \
      ~/.local/bin/asm-router ~/.local/bin/asm-stream-guard \
      ~/.local/bin/asm-clipd ~/.local/bin/asm-setup ~/.local/bin/asm-diag-dinit

And the leftover settings and audio configuration:

rm -rf ~/.config/arctis_manager
rm -rf ~/.config/pipewire/filter-chain.conf.d
rm -f  ~/.config/systemd/user/arctis-*.service
systemctl --user daemon-reload

Reboot at this point. ASM should be gone — nothing in the tray, nothing in the process list, no popup.

The popup at boot — separate bug, still open

I want to be straight with you rather than let you find out afterwards: the permissions popup at every boot is a different bug, and it is not fixed. I thought it was. @jsuvanto tested a clean install on 1 August and still got it, and I had missed that message until today. So if it comes back once you are on a clean install, that is not your setup failing again — it is this bug, and I am reopening it on the strength of your report and theirs.

What the clean-up should fix is the GUI detecting nothing and the settings you cannot change — both follow from the stale copy in ~/.local being loaded instead of the packaged one. If ASM still lingers after you close it once you are on a clean install, tell me and I will chase that one down separately rather than guess at it here.

Thank you for coming back a second time instead of giving up. Two weeks of "I must be doing this wrong" was the tool's fault, not yours, and both of the reasons are now closed off for whoever hits this next.

[loteran]

1.4.1 is out, and the fixed uninstaller is in it. As promised, here is the one command — nothing by hand:

curl -fsSL https://raw.githubusercontent.com/loteran/Arctis-Sound-Manager/main/scripts/uninstall.sh | bash -s -- --all --purge

It finds both installs — the Terra package and the ~/.local copy that survived everything — asks before each removal, and clears the settings and PipeWire configuration too. Reboot when it finishes, then:

sudo dnf copr enable loteran/arctis-sound-manager
sudo dnf install arctis-sound-manager

The popup at boot is fixed too

I said in my first reply that this was a separate bug and still open. I went looking, and it is fixed in this release as well — thanks to something @jsuvanto wrote on 1 August that I had missed.

The diagnosis was right all along: your dongle is enumerated early in the boot, before udev has applied its rules to it, so ASM's first attempt to open it fails even though your rules are perfectly valid. A retry existed for that. It was too small in two ways: it gave up after ten seconds, and once spent, nothing ever tried again — the budget was only refilled by a successful connection or by unplugging the dongle. On a setup like yours where the dongle never leaves its port, one slow boot meant the dialog stayed until you physically replugged it, and nothing in the running system would ever re-check.

That explains everything you both saw: why reopening the app "fixed" it (the service restarts, and gets a fresh attempt), and why the earlier fix looked like it did nothing.

ASM now keeps trying for a full minute before saying anything, and then goes on checking every thirty seconds instead of giving up. Rules that land late, or a fix applied from anywhere else, are picked up on their own. And if access comes back while the dialog is open, the dialog now closes itself rather than asking you to fix something that is no longer broken.

What to expect

After the clean install, the GUI should detect your headset, settings should stick, and the popup should be gone. If ASM still lingers after you close it, tell me — that one I did not want to promise without seeing it on a clean install first.

Thank you for coming back a second time instead of giving up. Both of the reasons the uninstaller could not see your installs are now closed off for whoever hits this next, and the popup you first reported in July is finally understood.

[DefactoCasual]

[DefactoCasual]

I did the commands manually and it seems to work so far, I'll get back to you if anything is still off

[DefactoCasual]

Ok, so after running the command to reinstall it (after i ran the complete uninstall check list of commands), it is now installed again, however, functionality still has not returned, I'm asked for the permission every time and my headset still reads as "not connected". Trying to alter any settings for the headset (again, microphone side tone) just prompts me to type my admin passcode in again to grant permissions.

[DefactoCasual]

Right click closing the program on the task bar also leaves it active in the system monitor.

[DefactoCasual]

Thanks for your time btw, feel like that needs to be mentioned from time to time