[PROBLEM] MoOde blocked after period of inactivity

[ECELO]

Good evening Tim, for about a year I have activated a Facebook group that deals with Dac on Raspberry and in particular with MoOde. Many of my users report MoOde crashes after some downtime. In fact I had found it myself on my system, but I was attributing it to some incompatibility with the Hat R38 card. I found instead that all those who complain about blocks are equipped with HDMI touchscreens or original Raspberry screens like the one actually mounted on my system. To solve the problem I initially disabled the local UI display verifying that the system actually remains stable, then I enabled the local UI display again by activating the screen blank and the Wake display on play. In this way the screen turns off after 2 minutes, but even if the system no longer plays music, it is still active and accessible after many hours. The culprit of this bug could be the Chromium saturating the RAM. Chromium, however, has a mechanism that avoids the continuous refresh and which is called Discard and which on a common browser can be activated with this command: chrome: // discards. Would it be possible to incorporate it into the next release? Thanks for your work and patience.

[Tim Curtis]

Yes, I think its some sort of chromium-browser bug. There are some reports on the Forum of similar issues and @TheOldPresbyope did some testing that seemed to confirm this in certain circumstances. I was never able to repro it in my environment.

Upcoming moOde 8 has a newer version of chromium-browser which may not exhibit the issue. We will have to wait and see how it behaves in the field. In the meantime I'll look at the Discard setting.

[TheOldPresbyope]

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.

[ECELO]

Yes, I think its some sort of chromium-browser bug. There are some reports on the Forum of similar issues and @TheOldPresbyope did some testing that seemed to confirm this in certain circumstances. I was never able to repro it in my environment.

Upcoming moOde 8 has a newer version of chromium-browser which may not exhibit the issue. We will have to wait and see how it behaves in the field. In the meantime I'll look at the Discard setting.

Thank you for your answer.

[ECELO]

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.

Thank you for your reply and for any pre-release testing.

[chaos333]

so is this solve currenlty before the 8.1 new version released?

what about for those non-firefox users?

i meet same problem using chrome brower and what to do with it now when i did not upgraded to 8.1.0?

thanks.

[Tim Curtis]

Starting with moOde 8.0.0 chromium-browser is automatically restarted every 2 hours as a workaround to the chromium bug that causes 100% memory utilization and system hang after ~2.5 hours. Google has still not isolated/fixed the bug.

I've tested other other browsers but they immediately peg the CPU to 100% so at this point chromium is the only viable option.
https://moodeaudio.org/forum/showthread....4#pid41014

[MisterD]

Good afternoon all,
I notice that there are a number of packages waiting to upgrade but all are being held back:

pi@moode:~ $ sudo apt list --upgradable
Listing... Done
camilladsp/bullseye 1.0.0-1moode1 armhf [upgradable from: 0.6.3-1moode2]
camillagui/bullseye 1.0.0-1moode1 all [upgradable from: 0.6.0-1moode1]
chromium-browser-l10n/stable 98.0.4758.106-rpt1 all [upgradable from: 95.0.4638.78-rpt6]
chromium-browser/stable 98.0.4758.106-rpt1 armhf [upgradable from: 95.0.4638.78-rpt6]
chromium-codecs-ffmpeg-extra/stable 98.0.4758.106-rpt1 armhf [upgradable from: 95.0.4638.78-rpt6]
raspberrypi-kernel/stable 1:1.20220331-1 armhf [upgradable from: 1:1.20220308-2]

I've tried upgrading chromium-browser but it seems to break the local display.

After testing all the browsers I could find I backed up MoOde, re-imaged the uSD card and restored. Worked beautifully
Now Chromium seems to be behaving really well (about 15% CPU) and MoOde always responds...where as before mine also kept going offline, apart from ping.

[Jedrek]

This problem i was noticed on https://moodeaudio.org/forum/showthread....8#pid40948