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
I have a problem with memory leak of /usr/bin/enigma2 crashing my receiver.
Describe the bug / Actual behaviour:
Every time a client such as Kodi with PVR plugin or Android TV/Fire TV app called DreamPlayer makes data request to my OpenATV receiver, the memory usage of the process /usr/bin/engima2 increases slightly. Eventually after a few days the receiver stops responding and needs to be rebooted.
Have a look at the screenshots below. I am monitoring my receiver using net-snmp-server plugin and LibreNMS.
Here is the screenshot of physical memory usage:
And here is the screenshot of network usage:
On the combined graph below, you can see that the memory usage increase happens every 2 hours, at exactly the same time as my clients are making data update queries:
Using ps or htop, I can see the memory usage of /usr/bin/enigma2 increasing every time a request is made by one of my clients.
This eventually leads to the receiver crashing once it runs out of available RAM.
Expected behaviour: /usr/bin/enigma2 process should free up the RAM once it is done providing requested data to remote clients.
Has this issue started to happen just recently?
It started a few months ago when I added 2 more remote clients to my household. I only got around to properly trace the root cause of the problem today though.
On a client of your choice such as Kodi with PVR plugin, or DreamPlayer installed on Android TV or FireTV:
Point the client app of your choice to the IPv4 address of the OpenATV receiver
Wait for it to sync channels, picons, EPG, and so on, or force the update
Back on the receiver:
Observe memory usage of /usr/bin/enigma2 increasing and not dropping back down to its previous level as the update completes.
Image/Box Model (please complete the following information):
Version: OpenATV 7.5.1.20250218 (2025-02-18)
BoxModel: Zgemma H9 TWIN
Additional context
Just for clarity, over the past few months I have reflashed my Zgemma receiver multiple times and kept the config as bare-bone as possible to isolate this issue.
The text was updated successfully, but these errors were encountered:
Hello,
I have a problem with memory leak of
/usr/bin/enigma2
crashing my receiver.Describe the bug / Actual behaviour:
Every time a client such as Kodi with PVR plugin or Android TV/Fire TV app called DreamPlayer makes data request to my OpenATV receiver, the memory usage of the process /usr/bin/engima2 increases slightly. Eventually after a few days the receiver stops responding and needs to be rebooted.
Have a look at the screenshots below. I am monitoring my receiver using
net-snmp-server
plugin and LibreNMS.Here is the screenshot of physical memory usage:
And here is the screenshot of network usage:
On the combined graph below, you can see that the memory usage increase happens every 2 hours, at exactly the same time as my clients are making data update queries:
Using
ps
orhtop
, I can see the memory usage of/usr/bin/enigma2
increasing every time a request is made by one of my clients.This eventually leads to the receiver crashing once it runs out of available RAM.
Expected behaviour:
/usr/bin/enigma2
process should free up the RAM once it is done providing requested data to remote clients.Has this issue started to happen just recently?
It started a few months ago when I added 2 more remote clients to my household. I only got around to properly trace the root cause of the problem today though.
To reproduce:
Steps to reproduce the behavior:
On the receiver:
On a client of your choice such as Kodi with PVR plugin, or DreamPlayer installed on Android TV or FireTV:
Back on the receiver:
/usr/bin/enigma2
increasing and not dropping back down to its previous level as the update completes.Image/Box Model (please complete the following information):
Additional context
Just for clarity, over the past few months I have reflashed my Zgemma receiver multiple times and kept the config as bare-bone as possible to isolate this issue.
The text was updated successfully, but these errors were encountered: