Processing stops on window close

[ghost]

EasyEffects Version

6.1.3

What package are you using?

Flatpak (Flathub)

Distribution

Arch Linux

Describe the bug

Easyeffects stops processing when the window is closed. Launching it from the terminal the process stops the second the window is closed. I've tried both the AUR and Flatpak versions with the same result. I've also had the same result across EndeavourOS and Arch.

I have it set to process all out/inputs and have not set it to shutdown on window close.

Expected Behavior

Continuous processing.

Debug Log

No response

Additional Information

No response

[wwmm]

Which desktop enviroment are you using(kde, gnome, etc)? I am also on Arch Linux and the package from the repository works fine. When I click on EasyEffects icon its process is started in service mode and its window can be closed. But it seems that not all desktops support the dbus service needed for this. In this case the user has to start our process in service mode by hand easyeffects --gapplication-service. After that click on its icon to open the window.

Another thing to try after going back to the native package from the repository is enabling Start Service at Login and do the login in your desktop again. An autostart file will be created inside ~/.config/autostart/ that will start easyeffects on login already in service mode.

[ghost]

Yeah I've had it run fine in Gnome, but since I switched to WMs it has stopped processing when the window is closed. I've had this issue on Openbox, Qtile and Bspwm. Autostart is enabled in the Easyeffects settings, but this does not seem to be respected. Adding easyeffects & to the WMs autostart scripts starts the GUI (how do I start it as a bg service?) at which point it does process audio, but I want it to run in the background.

[vchernin]

The built in EasyEffects start at login switch should make it start in the background.

I wonder if this is an X11 issue, AFAIK all those WMs haven't gotten Wayland support yet right? Were you running Gnome in Wayland?

[ghost]

No, ran Gnome and all the WMs in X11 due to Nvidia drivers.

[wwmm]

Adding easyeffects & to the WMs autostart scripts starts the GUI (how do I start it as a bg service?) at which point it does process audio, but I want it to run in the background.

What our autostart file does is executing easyeffects --gapplication-service in the login. If you click on easyeffects icon or run easyeffects in a terminal while easyeffects --gapplication-service is running you can close its window without loosing the effects.

[ghost]

So I added easyeffects --gapplication-service to the Openbox autostart script which made no difference. It does not process until I open the GUI and when I close it processing stops. Cannot find the process with pgrep easyeffects when the GUI is closed, so it doesn't seem to be running at all.

[wwmm]

So I added easyeffects --gapplication-service to the Openbox autostart script which made no difference.

What happens if you execute it manually in a terminal instead of trying to make Openbox initialize it in the login? Does it die or does it keep running?

[ghost]

So the reason adding easyeffects --gapplication-service to the Openbox autostart script did nothing was because I am in fact running the Flatpak version (it was the last one I tried and I had forgotten). Installed the AUR version and started it with easyeffects --gapplication-service and now it a) starts and b) runs when the GUI is closed.

Having said that, without easyeffects --gapplication-service in the Openbox script (but with the Easyeffects autostart option toggled in the GUI) it still does not start, and stops processing when the GUI is closed.

My issue is solved, so feel free to close this, but perhaps it is still worth looking into as the toggle is still broken/not respected.

[wwmm]

but perhaps it is still worth looking into as the toggle is still broken/not respected.

The problem is that it does not look like I can fix this on my side. From the applications point of view all we have to do is creating the autostart file inside ~/.config/autostart/. All the rest is done by the desktop environment. Same thing for the dbus feature we use to make EasyEffects start as service when the user clicks on our icon in the app launcher. Each desktop environment where these things are not working will need its own kind of fix. It is out of my reach doing such a thing.

[ghost]

Bit of a followup, but don't think it warrants a new issue. Different machine but same situation: Arch, Flatpak install. Adding easyeffects --gapplication-service to autostart does not work because bash/zsh does not interpret 'easyeffects' as a command.
zsh: command not found: easyeffects
Any ideas?

[vchernin]

This is just how Flatpak works, easyeffects is not set as a executable available on your normal path.

You should be able to use the built in switch for autostart with Flatpak.

[quietvoid]

This has started happening to me, where the running easyeffects --gapplication-service gets killed if I quit another instance of easyeffects.
Not sure what changed on my system (or the app). I run Sway so there's not even an icon to open the running service.

I might try bisecting later today.

[vchernin]

This has started happening to me, where the running easyeffects --gapplication-service gets killed if I quit another instance of easyeffects.

Not sure what changed on my system (or the app). I run Sway so there's not even an icon to open the running service.

I might try bisecting later today.

I'm not sure if that's the same bug, what package are you using? A Flatpak has more controlled permissions than other packages, and that can cause weird behaviour. Flathub-beta (see readme) behaves a bit better but it still needs improvement.

From the applications point of view all we have to do is creating the autostart file inside ~/.config/autostart/

That, or for Flatpak we ask a portal to do it for us. But that depends on a functional portal setup on the host, which depends on functional D-Bus on the host. All of which is basically out of our control.

[quietvoid]

I'm using easyeffects-git from the AUR.
I've found multiple issues similar to this so I didn't create a new one yet.

My setup is pretty much the same as proposed for #1140

[wwmm]

I'm using easyeffects-git from the AUR.

Strange. Although I do not use the pkgbuild from AUR(I use the one we have here in github) I am also on Arch Linux and I do not remember having seen something like this. Maybe it is better you open a new issue with some logs from your system.

[russelltg]

One interesting thing I noticed is that when rofi runs easyeffects, it runs it without --gapplication-service flag, but if I run it with gtk-launch it runs with --gapplication-service. Looking at the code for it it seems gtk-launch is using dbus activation instead of just running the Exec line in the desktop file. Is it correct that the desktop file doesn't have --gapplication-service in the Exec line, or should rofi be doing dbus activation?

[wwmm]

Is it correct that the desktop file doesn't have --gapplication-service in the Exec line, or should rofi be doing dbus activation?

Yes. Rofi should be using dbus activation. If you just run easyeffects --gapplication-service directly EasyEffects will be launched as a background process without showing its window. The way to show its window while activating the "service mode" at the same time is using the dbus activation feature.

The --gapplication-service is a gtk feature that allows an ordinary app to run in the background and pretend to be a service. Somehow under the hoods gtk interacts with dbus and does all this magic when the user clicks on our launcher icon.

[wwmm]

More information about this in this page https://wiki.gnome.org/HowDoI/DBusApplicationLaunching