02-15-2022, 10:28 PM
Hi, @ECELO
As you can see if you examine the running processes from the command line using the top command, say, enabling the local display causes chromium-browser to start and immediately spawn many more chromium-browser helper processes.
In the past, it has been the --type=renderer process which seems to eat all of available memory after a time. I've not been able to determine what triggers this behavior. As Tim says, we can hope the latest release behaves better but there's no guarantee.
I seemed to suffer this problem only when I used an HDMI display but I haven't been using one lately. [1]
At least one user has reported success avoiding this problem by modifying moOde to use firefox instead of chromium-browser. There are minuses to this approach, to be sure, but keeping moOde responsive is a definite plus
Regards,
Kent
[1] Now that the issue has come up again, I've set up a copy of pre-release (TestTeam only) moOde 8 to see if there's been any change in chromium-browser behavior.
As you can see if you examine the running processes from the command line using the top command, say, enabling the local display causes chromium-browser to start and immediately spawn many more chromium-browser helper processes.
In the past, it has been the --type=renderer process which seems to eat all of available memory after a time. I've not been able to determine what triggers this behavior. As Tim says, we can hope the latest release behaves better but there's no guarantee.
I seemed to suffer this problem only when I used an HDMI display but I haven't been using one lately. [1]
At least one user has reported success avoiding this problem by modifying moOde to use firefox instead of chromium-browser. There are minuses to this approach, to be sure, but keeping moOde responsive is a definite plus
Regards,
Kent
[1] Now that the issue has come up again, I've set up a copy of pre-release (TestTeam only) moOde 8 to see if there's been any change in chromium-browser behavior.
