Summary
OpenPlotter Notifications can leave openplotter-notifications-sound running
for days after the original sound-producing notification is no longer the
current aggregate Signal K value. The helper replays a sound every ~3 seconds,
spawning VLC repeatedly.
In my case this caused sustained PulseAudio/PipeWire stream churn to Dummy
Output and triggered a severe memory leak in lxpanel's volumepulse plugin.
Environment
- OpenPlotter Notifications: 4.5.0
- OS: Debian GNU/Linux 12 bookworm on Raspberry Pi
- Audio: PulseAudio on PipeWire 1.2.7
- Default sink:
auto_null / Dummy Output
Observed process chain
openplotter-notifications-read 0
openplotter-notifications-sound notifications.navigation.anchor normal 2026-04-26T01:59:56.585Z vessels.[redacted]
cvlc --play-and-exit /usr/share/sounds/openplotter/Bleep.mp3
The sound helper was still running on 2026-04-30 after being launched on
2026-04-26.
Signal K state
The original source value was:
source: hoekens-anchor-alarm
path: notifications.navigation.anchor
state: normal
message: Started
method: ["visual", "sound"]
timestamp: 2026-04-26T01:59:56.585Z
The current aggregate Signal K value later became:
source: signalk-anchoralarm-headless-plugin
state: normal
message: ""
method: []
Despite method: [], the old sound helper continued replaying because it only
checks whether the current notification state is still normal.
Suspected code behavior
In openplotterNotifications/sound.py, the repeat loop checks only whether the
current notification path still exists and whether its state still matches the
original state. It does not check whether:
- the current
method still includes sound
- the current message still matches the original message
- the current source still matches the original source
- the current notification id still matches the original id
Impact
This can produce unbounded repeated sound playback attempts. On my system it
created repeated VLC/PulseAudio/PipeWire stream churn and, when the LXPanel
volumepulse plugin was loaded, caused lxpanel private dirty memory growth of
about 87 MB/hour.
Suggested fix
For repeatable sounds, stop the helper when the current notification no longer
has sound in method, or when the original source/message/id no longer match.
Alternatively, do not repeat normal notifications by default.
Summary
OpenPlotter Notifications can leave
openplotter-notifications-soundrunningfor days after the original sound-producing notification is no longer the
current aggregate Signal K value. The helper replays a sound every ~3 seconds,
spawning VLC repeatedly.
In my case this caused sustained PulseAudio/PipeWire stream churn to Dummy
Output and triggered a severe memory leak in
lxpanel'svolumepulseplugin.Environment
auto_null/ Dummy OutputObserved process chain
The sound helper was still running on 2026-04-30 after being launched on
2026-04-26.
Signal K state
The original source value was:
The current aggregate Signal K value later became:
Despite
method: [], the old sound helper continued replaying because it onlychecks whether the current notification state is still
normal.Suspected code behavior
In
openplotterNotifications/sound.py, the repeat loop checks only whether thecurrent notification path still exists and whether its
statestill matches theoriginal state. It does not check whether:
methodstill includessoundImpact
This can produce unbounded repeated sound playback attempts. On my system it
created repeated VLC/PulseAudio/PipeWire stream churn and, when the LXPanel
volumepulseplugin was loaded, causedlxpanelprivate dirty memory growth ofabout 87 MB/hour.
Suggested fix
For repeatable sounds, stop the helper when the current notification no longer
has
soundinmethod, or when the original source/message/id no longer match.Alternatively, do not repeat
normalnotifications by default.