You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[QUESTION] Should StreamController use this much RAM? #123
Fairly high RAM usage by StreamController. Is this caused by a memory leak, or is it by design? I have plenty of RAM so it's not affecting me personally, but I'm just wondering if it's by design or not.
Yeah, high memory usage is still a big problem. I think it is related to the actions as the consumption grows when adding actions and switching pages. I hope I can fix this soon
@pnmtech Thank you for the links! However, I think the issue is caused by the app itself, because the same problem appears when using it outside of Flatpak
It isn't just the RAM usage, CPU as well, both Flatpak or otherwise. Both get worse if you just make a button show the percentage of CPU or RAM used, and just press that button rapidly. I also wonder if it's something in the underlying Python layer that StreamController uses?
FWIW: The screenshot from @Linuturk is not an issue with StreamController, but rather a bug with xdg-proxy as seen here: flatpak/xdg-dbus-proxy#51. They have supposedly fix this, but have not released the fix yet
Some things that can help here:
What does the total memory landscape look like. Using atool like htop can make this easier to see, as it is helpful to see VIRT vs RES vs SHR memory (this is also shown in the original screenshot report from whatever app that is)
Thanks. The xdg-dbus-proxy is the issue I linked above, it is unfortunately not somethin we can fix and requires an upstream fix. That screenshot also doesn't really provide information if that memory column is virtual memory or resident memory. Not a huge deal, but would help in understanding how big of an issue this is (virtual memory is just how much memory has been requested by the application, now how much is actively being used)
I'm running 1.5.0-beta.13 and StreamController uses 22GB of memory after 6 days
Have anyone tested #527 and can confirm if it fixes the leak or not?
If it's still not fixed I might be able to help look into it (figured I should ask here first before investing time running an unreleased version to repro and debug it..)
Have anyone tested #527 and can confirm if it fixes the leak or not?
If it's still not fixed I might be able to help look into it (figured I should ask here first before investing time running an unreleased version to repro and debug it..)
I've been testing it for a few days and still had memory issues
I'm running 1.5.0-beta.13 and StreamController uses 22GB of memory after 6 days
If it's still not fixed I might be able to help look into it (figured I should ask here first before investing time running an unreleased version to repro and debug it..)
Just a quick update, I'm profiling 1.5.0-beta.14 right now but noticed that the memory usage isn't really growing. Either it need a specific usage pattern to trigger a sudden memory leak, or the bug has been fixed in 1.5.0-beta.14. I'll keep using the app normally under the profiler and see how it goes
Since the latest update, the StreamController process itself has stopped taking up a ton of memory for me, but it is still causing flatpak-session-helper to take up several gigabytes over time. StreamController is the only flatpak I have constantly running so it has to be the one using all the RAM.
I had ChatGPT do an analysis on the entire codebase to see if it could find any issues that could cause a memory leak, and it pointed out that a new flatpak-spawn --host instance is launched every 200ms on Sway, KDE, X11, and Hyprland/Mango WindowGrabber integrations. I lack the expertise to understand how to troubleshoot that, but it's probably worth someone looking into further.
Activity
Core447 commentedon Jun 2, 2024
Yeah, high memory usage is still a big problem. I think it is related to the actions as the consumption grows when adding actions and switching pages. I hope I can fix this soon
pnmtech commentedon Jun 22, 2024
I just realized to a much lesser extent that I have the same issue and with some short research I found m this flatpak/xdg-dbus-proxy#51 and apparently the fix was found in https://github.com/sailfishos/xdg-dbus-proxy/blob/master/rpm/0001-Fix-GVariant-reference-leaks.patch I am not good with programming so I have no idea if my input was needed in the first place. I'm just trying to help. Really love the software. I've been enjoying using it
Core447 commentedon Jun 23, 2024
@pnmtech Thank you for the links! However, I think the issue is caused by the app itself, because the same problem appears when using it outside of Flatpak
NightSprinter commentedon Jun 23, 2024
It isn't just the RAM usage, CPU as well, both Flatpak or otherwise. Both get worse if you just make a button show the percentage of CPU or RAM used, and just press that button rapidly. I also wonder if it's something in the underlying Python layer that StreamController uses?
Core447 commentedon Jun 23, 2024
The graphs or the "normal" ones? Because the graphs take up a huge amount of memory (that's why I added a warning in their config area).
I hope I can fix those issues soon, but it'll probably take some time to find the issues
Linuturk commentedon Jun 16, 2025
Wanted to chime in that I'm seeing this behavior as well, leading to resource contention on my system.
When you first start StreamController, memory usage is minimum.
But over a day or two, you can see memory usage has exploded, and just gets worse over time.
Phrozenn1 commentedon Oct 14, 2025
1.8GB is my current record. I hope this get fixed soon
Dragonsong3k commentedon Oct 14, 2025
Out of curiousity, does your StreamDeck freeze up when the memory is high?
ImDevinC commentedon Oct 15, 2025
FWIW: The screenshot from @Linuturk is not an issue with StreamController, but rather a bug with xdg-proxy as seen here: flatpak/xdg-dbus-proxy#51. They have supposedly fix this, but have not released the fix yet
Some things that can help here:
Dragonsong3k commentedon Oct 15, 2025
Here is my load out if it helps.
I have 1 page with various buttons from those plugins.
The buttons I have configured
From what I see, it's the xdg process and the Python process pulling about 3.5 GBs of ram after a full days usage.
The StreamDeck+ will also lock up after about a day of usage. I am not 100% convinced it is related to the memory usage.
I can get more details when I get back to my system.
ImDevinC commentedon Oct 15, 2025
Thanks. The xdg-dbus-proxy is the issue I linked above, it is unfortunately not somethin we can fix and requires an upstream fix. That screenshot also doesn't really provide information if that memory column is virtual memory or resident memory. Not a huge deal, but would help in understanding how big of an issue this is (virtual memory is just how much memory has been requested by the application, now how much is actively being used)
32 remaining items
sifmelcara commentedon May 17, 2026
I'm running
1.5.0-beta.13and StreamController uses 22GB of memory after 6 daysHave anyone tested #527 and can confirm if it fixes the leak or not?
If it's still not fixed I might be able to help look into it (figured I should ask here first before investing time running an unreleased version to repro and debug it..)
Elip100 commentedon May 20, 2026
I've been testing it for a few days and still had memory issues
notmugi commentedon May 22, 2026
if anyone has looked into #558 it looks very promising. haven’t tested the ram improvements myself but it seems to do quite a bit.
sifmelcara commentedon Jun 5, 2026
Just a quick update, I'm profiling
1.5.0-beta.14right now but noticed that the memory usage isn't really growing. Either it need a specific usage pattern to trigger a sudden memory leak, or the bug has been fixed in1.5.0-beta.14. I'll keep using the app normally under the profiler and see how it goessifmelcara commentedon Jun 7, 2026
@Elip100 did you delete your comment? I wonder what's the situation on your side.
On
1.5.0-beta.14it seems like there is still leak. But now it only leaks ~15MB per hour, instead of ~200MB per hour in1.5.0-beta.13.Elip100 commentedon Jun 9, 2026
It's definitely slower but it's still leaking. It's slow enough that I reboot often enough for it to not affect me that much.
Kathund commentedon Jun 27, 2026
I seam to be having the same thing just a big higher scale then 15mb an hour
I'm running
1.5.0-beta.14from nixpkgsI think this might also be the highest I have seen
fix(deck): dispatch dial/touchscreen events to their read-time actions
Merge branch 'fix/pageflip-action-lifecycle' into 'main'
Core447 commentedon Aug 10, 2026
eb2bc60 massively improved this for me
Kathund commentedon Aug 18, 2026
Built the 1.5.0-beta.16 from source and it seams to be a lot better
Core447 commentedon Aug 19, 2026
Great!
jleaders commentedon Oct 7, 2026
I'm still seeing this issue on the latest flat pack release.
Elip100 commentedon Oct 8, 2026
Since the latest update, the StreamController process itself has stopped taking up a ton of memory for me, but it is still causing flatpak-session-helper to take up several gigabytes over time. StreamController is the only flatpak I have constantly running so it has to be the one using all the RAM.
Elip100 commentedon Oct 8, 2026
I had ChatGPT do an analysis on the entire codebase to see if it could find any issues that could cause a memory leak, and it pointed out that a new
flatpak-spawn --hostinstance is launched every 200ms on Sway, KDE, X11, and Hyprland/Mango WindowGrabber integrations. I lack the expertise to understand how to troubleshoot that, but it's probably worth someone looking into further.