[Bug]: mini-eq stops processing after some time

[jtl5770]

Before opening

• I searched existing issues for a similar report.
• This is not a security vulnerability.

Affected area

Other

Mini EQ version

0.8.1

Install method

Flathub

Linux distribution and version

Fedora 44

Desktop/session

Gnome Wayland

PipeWire and WirePlumber versions

No response

Steps to reproduce

Open youtube, play something.
Let mini-eq do its thing. Wait a while (and here is what seems be true, but maybe I just havn't experienced otherwise) after there is no more sound output from the system.
Start playing a video again .

Expected behavior

mini-eq processes audio of the second video

Actual behavior

no more processing though the controls indicate that mini-eq should still be working. No change in routing by switching between headphones and speakers need to take place. The amount of time is not always the same, it doesn't always happen, but whenever I leave the laptop alone and come back to listen to audio again it seems to be switched off.
Maybe there is some connection to locking the session/switching the screen off? But a quick check to trigger it by locking the session didn't reveal the bug.

So we are either back to where we have been at a couple of versions ago or introduced something new - or I didn't test enough the last time.

Logs or terminal output

[bhack]

Thanks, this sounds like the routing/processing path becomes stale after an idle period rather than the UI switch itself turning off.

When it happens again, before toggling anything, could you please capture:

flatpak info io.github.bhack.mini-eq
wpctl status
pw-link -l
journalctl --user --since "10 minutes ago" | grep -iE "mini-eq|pipewire|wireplumber|filter-chain"

The key thing I want to see is whether the playback stream is still connected to mini_eq_sink, and whether the filter-chain output is still linked/active to the real output sink.

Also useful:

• Does toggling only System Audio off/on revive it?
• Does toggling only Monitor off/on revive it?
• Does changing one EQ band revive it without touching routing?
• Which browser/player was used when it happened?
• Which PipeWire and WirePlumber versions are installed?

This may be related to the earlier idle/routing issue, but from your description this one sounds narrower: Mini EQ still believes routing is enabled, while the actual PipeWire processing path may no longer be active after silence, screen-off, or stream recreation.

[bhack]

Also an extra info when this happens, did the machine auto-suspend, or was it only locked/screen-off?

[jtl5770]

Some questions I can answer rtight away:

• Machine was NOT suspended.
• It does NOT only happen on screen lock / off
• Player was just youtube in chrome
• flatpak info io.github.bhack.mini-eq

Mini EQ - Tune your sound output

        ID: io.github.bhack.mini-eq
       Ref: app/io.github.bhack.mini-eq/x86_64/stable
      Arch: x86_64
    Branch: stable
   Version: 0.8.1
   License: GPL-3.0-or-later
    Origin: flathub
Collection: org.flathub.Stable

Installation: system
Installed Size: 71.6 MB
Runtime: org.gnome.Platform/x86_64/50
Sdk: org.gnome.Sdk/x86_64/50

    Commit: b492cef597f6021f61e63513b7626c5e5bdf40cb0ae72228e2dac3c2c1695641
    Parent: 46f8995d50350836b8099a42fa8acaad29ba329efbe049abce02fe86697dcfc9
   Subject: Merge pull request #22 from flathub/update-0.8.1 (24b93dd424aa)
      Date: 2026-05-14 17:40:26 +0000

[jtl5770]

would the following help to make it more robust:

diff --git a/src/mini_eq/pipewire_stream_router.py b/src/mini_eq/pipewire_stream_router.py
index 35e0110..8473f98 100644
--- a/src/mini_eq/pipewire_stream_router.py
+++ b/src/mini_eq/pipewire_stream_router.py
@@ -318,6 +318,8 @@ class PipeWireStreamRouter:
         if self._link_touches_processing_path(link):
             self.track_processing_link_state(link)
             self.schedule_refresh(route_applied=True)
+        else:
+            self.schedule_refresh()
 
     def handle_object_removed(self, _manager, node) -> None:
         try:
@@ -326,6 +328,7 @@ class PipeWireStreamRouter:
             return
 
         self.untrack_processing_link_state(link)
+        self.schedule_refresh()
 
     def untrack_processing_link_states(self) -> None:
         for handler_id in list(self.link_state_handler_ids.values()):

[bhack]

it seems too broad... the risk is it is that it is going to react to "noise".
Without the log it is hard to modelling your case but I've tried to simulate it at best as as it was described:

Can you stress test this version:
flatpak install --user -y https://dl.flathub.org/build-repo/284925/io.github.bhack.mini-eq.flatpakref
flatpak run io.github.bhack.mini-eq

[jtl5770]

I will try that one. In the meantime I have updated the patch to include Node State Monitoring. Mini EQ now explicitly watches the status of the nodes in its processing path (the virtual sink, the filter output, and your hardware speakers).

Whenever any of these nodes transition to the running state, Mini EQ will now:

1. Recalculate the EQ coefficients for the current (possibly new) sample rate.
2. Re-apply all filter parameters to the engine immediately.
3. Verify that routing is still correct.

Maybe still too much done for your taste, so just ignore if it is rubbish.

fix-processing-loss.patch

[jtl5770]

May it have made a difference that I now run it with the monitoring turned off to spare some cycles? If the theory about suspending/resuming is correct, having the little monitor in the extension may have been enough to keep things always running? Just a wild guess. I will of course still send you your logs whenever I see it happen again.

[bhack]

Thanks, that extra clue is useful. Please test the Flathub build with the same setup that triggers the issue, especially with Mini EQ monitoring turned off if that is how you now run it:

flatpak install --user -y https://dl.flathub.org/build-repo/284925/io.github.bhack.mini-eq.flatpakref
flatpak run io.github.bhack.mini-eq

If it happens again, before toggling Mini EQ, please capture:

wpctl status
pw-link -l
journalctl --user --since "10 minutes ago" | grep -iE "mini-eq|pipewire|wireplumber|filter-chain"

Your node-state patch is useful as a reference, but I want to first verify the narrower relink recovery fix. If this build still fails, the next thing to investigate is probably node resume/running state and whether we need to re-apply filter controls after PipeWire wakes the processing path.

Also, could you check whether turning Mini EQ monitoring back on makes the issue disappear or become harder to reproduce? That would be a strong signal that the graph is being kept active by the monitor path.