Thank you for your donation!


Cloudsmith graciously provides open-source package management and distribution for our project.


Local display function fails with HDMI in moOde 7.0.1
#52
(04-19-2021, 12:55 PM)bgonc Wrote: Hi 

first time contributor to the forum,  loving Moode since early 2020 .

I have a raspberry Pi 3B with an Hifiberry DAC + Pro and an Osoyoo 3.5" DSI touch screen and with Moode 7.1.0 installed 

I verified a similar problem with Chromium memory usage increasing until freezing Moode completely. This started to happen since, at least, version 7.0.1 (although looking retrospectively  I had previously several Chromium Aw! Snap Windows the could be from a similar problem). The problem occurs typically around 27 minutes after pausing the music player.

Trying to avoid being a "Me too!" I used the Local UI display with HDMI on , and with HDMI off while using the DSI display . Independently of the HDMI it always resulted in  the system becoming completely frozen after some time.

Although not proficient in Linux , I think  I found a work around to prevent the problem to occur. I edited the file .xinitrc and added at the end of the chromium-browser launch line:

--single-process --no-zygote --no-sandbox

It is now paused for more than 1 hour without any signs of increase in memory usage (with htop  showing memory usage  to vary between 236 and 259 Mb).

PS: I do not know why it works but I realized using top that the Chromium  process that was using the memory had  a "type=zygote"  and tried to follow from there.

Thanks for the input.

I have never in the past been able to repro the OOM problem using a DSI touchscreen for local display, only with HDMI enabled.

However, I have again started a testbox with DSI touchscreen on an RPi3B+ running moOde 7.1.0. I left MPD paused on a track from my SMB server. It's been 45 minutes and nothing unusual has occurred yet. We'll see.

In all my observed cases it was the single renderer subprocess which ate memory, not any of the zygote subprocesses so I don't understand what is causing what you observe. On my testbox there are 3 zygote subprocesses running, one of which is set --no-zygote-sandbox

zygote is a helper subprocess whose purpose is to launch other subprocesses, notably the renderer; consult your favorite search engine to find out why zygote is used with Linux but not with Windows or MacOS. It is certainly possible to run without it (at the expense of a more fragile browser but this may not matter in our use case). The sandbox feature of chromium-browser doesn't work without it so it must be disabled at the same time, just as you have done. Disabling the latter is meant by the chromium devs for testing purposes only but if this action "fixes" our issue that's valuable info.

Setting --single-process approaches the chromium-browser behavior in a very different way and I'm not sure why it would also be required. Did you find some supporting evidence elsewhere for setting it? Did you try it by itself?

If I can't Whether or not I can succeed in reliably triggering a failure with DSI local display I'll revert to an HDMI display where I know I can observe failure and try your settings with it.

Regards,
Kent

PS - I think I'll retitle the thread to reflect the broadened scope.
Reply


Messages In This Thread
RE: Local display function fails with HDMI in moOde 7.0.1 - by TheOldPresbyope - 04-19-2021, 05:14 PM

Forum Jump: