Page MenuHomeSolus

Pulseeffects aborts at launch
Closed, ResolvedPublic

Description

Assertion 'o' failed at pulse/operation.c:133, function pa_operation_get_state(). Aborting.
[1]    2187 abort      pulseeffects

is what I get when I try to launch Pulseeffects. It creates sinks and shows a notification, but never launches gui

Solus Budgie, current kernel, intel i5-5200

Event Timeline

K4rlos created this task.Sep 24 2018, 1:04 PM
JoshStrobl edited projects, added Software; removed Lacks Project.Sep 24 2018, 1:33 PM
JoshStrobl closed this task as Resolved.Sep 24 2018, 1:38 PM
JoshStrobl claimed this task.
JoshStrobl added subscribers: kyrios123, JoshStrobl.

I've landed R3867:008ad78626b29f2cce4cda9a629f116f05fa85e7 from @kyrios123 and pushed it to stable. If the issue persists, feel free to re-open this task.

K4rlos reopened this task as Open.Sep 24 2018, 1:48 PM

Unfortunately, the bug still exists

I'm not able to reproduce the issue. Do you have any sort of custom pulseaudio configuration set?

K4rlos added a comment.EditedSep 24 2018, 1:58 PM

I managed to solve the issue. I should've spent more time trying to fix it before posting here, but

dconf reset -f /com/github/wwmm/pulseeffects/

solves the problem.

Pulseeffects is known to cause problems after updates. There is a built-in way to reset configuration of pulseeffects, but it fails to run it, because, ironically, the problems won't let that happen.

Maybe it's possible to add that command to eopkg update process? I know it requires dconf, but removing configuration folder doesn't solve this issues, that command does.

The command doesn't remove any saved presets, so no settings are lost

K4rlos closed this task as Resolved.Sep 24 2018, 1:59 PM

Maybe it's possible to add that command to eopkg update process? I know it requires dconf, but removing configuration folder doesn't solve this issues, that command does

While that may sound ideal, it is slightly problematic as it would involve a temporary usysconf trigger. I say temporary as it can't be reasonably expected, in my opinion, that these sorts of configuration issues on their part continue to occur long into the future. Ideally they'd take into consideration properly upgrading schemas and gradually phasing old keys out.