Local display function fails with HDMI in moOde 7.0.1

[Alaini93]

Wow! good news, I have the exact same set up.
I hope the pros will approve
I will try it this evening.
Thanks

[TheOldPresbyope]

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.

[bgonc]

Hi

I was looking for similar problems with Chromium and found on a forum someone describing running into memory problems (unfortunately I did not save the link but was a completly different appplication) . There, it was suggested to use —no-zygote —no-sandbox together with —single-process . Although in that particular case it seemed that —single-process made no difference I decided to try the three possible combinations:
1) —no-zygote —no-sandbox
2) —single-process
3) —no-zygote —no-sandbox —single-process

Only 3) seemed to work. I verified during this afternoon that the rpi stil has some memory excursions up to 700Mb but than return to normal usage . I will recheck with option 1) and 2) as now I wonder If I stopped the rpi before allowing the memory usage return to normal values and assumed it was going to freeze

I will also check the exact process that was running into problems

The system was now running for 6h42m . I listened radio for a while and paused in the last 2 hours without any problem

Regards

Bruno

[bgonc]

Hi Kent

I tried again to reboot with the 3 options
1) —no-zygote —no-sandbox
2) —single-process
3) —no-zygote —no-sandbox —single-process

The option 2) seems to prevent the OOM event (only with occasional excursions to 700 Mb usage). The system is now running for more than 2 hours without any problem after pausing the music for more than 1 hour. With option 1) the system freezes due to OOM

It seems that adding —single-process to the chomium-browser launch options tame the memory usage

My apologies for the first misleading post

Cheers
Bruno

[Alaini93]

1 hour and still working, looking good

[Alaini93]

2 hours, party pooper kswap came over.

[TheOldPresbyope]

@bgonc

I am using a USB DAC on my DSI touchscreen-equipped testbox and I haven't seen any memory usage problem with hours of testing on an unmodified moOde 7.1.0 installation. 

I restarted chromium-browser with the --single-process option and it also has been running for hours now without any memory usage problem. Actually the memory usage dropped some 60MB because of the fewer number of subprocesses (this is mentioned in the design docs). There are some interesting anomalies. For example, 3 zygote subprocesses are running, just as before. 

At this point, I suppose I'd say this is may be a viable band-aid solution for those who experience the problem but I won't feel comfortable until I know the root cause. The chromium dev design docs say of this option

The single process model provides a baseline for measuring any overhead that the multi-process architectures impose. It is not a safe or robust architecture, as any renderer crash will cause the loss of the entire browser process. It is designed for testing and development purposes, and it may contain bugs that are not present in the other architectures.

Since the OOM condition results in catatonia for us, their architectural caveat may be moot but the "may contain bugs" remark is sobering.

I just noticed your system includes an I2S HiFiBerry DAC+ as does @Alaini93's. Several other contributors to this issue are using I2S HiFiBerry AMP2. I thought we'd shown the coincidence likely was a red herring up-thread but curiously it keeps recurring. I think I have a DAC+ around somewhere but I have no easy way of inserting it into the system containing my touchscreen.

Starting HDMI test later.

Regards,
Kent

ETA - but I just saw @Alaini93 's follow-up post so maybe not such a good band-aid solution after all.

[bgonc]

Hi

my system is now running for 13 hours. I will leave it in this state until further insights into the problem appears .
One point I did not mention, but may not be important, is that I am using Ethernet only (my son toasted the RF chip two years ago )

Also another detail that may or may not have any importance: I updated Chromium-browser to the latest version - 88.0.4324.187-rpt1

Thank you for your efforts

cheers
Bruno

[Alaini93]

Still crashing with 7.2 and DSI screen

[gforster]

   

Still crashing with 7.2 and DSI screen

Hi all,

confirm what Alaini93 is seeing.

I do have a similar configuration: RPi 3B+, Iqaudio DigiAMP+ and local 7" touch connected through DSI, LAN connection.
The issue is reproducable and occurs in my setup after 2 hours when mpc is in status "paused". This is the standard status when I set the radio into standby mode late evening through IR remote lirc that disables the LCD backlight and execuctes "mpc toggle" command.
I observed the supply voltage with the oscilloscope (no anomalies).

Tried the following tests in order to further isolate the problem:

• moode 7.1.0
  
• moode 7.2.0
  
• enabled HDMI-I/F in addition to local DSI
  
• replaced the "mpc toggle" command by "http://<Moode-Host-Name>/command/?cmd=pause"
  
• various tests with chromium parameters: Adding "--single-process" or "no-zygote --no-sandbox --single-process"
  btw: By comparing the .xinitrc file from moode 6.x with 7.x there is a small typo in the parameter setting in the current .xinitrc file. The enable-features option is missing a "-". It currently reads "-enable-features=OverlayScrollbar". But even correcting this to "--..." didn't make it running
  

After 2 hours of player inactivity, the memory gets swallowed by serveral chromium processes and the green RPi activity LED is continuously illuminated.
htop is indicating that the system is dead. I know that the meaning of process status "D" is different to dead, but I use it as an indication that the system is screwed. Chromium is consuming ~98% of the available memory.



I don't believe this is a moode problem, but more a chromium issue in combination with pi-OS. Nevertheless, I wanna have a radio that continues to play songs even the radio was in pause mode over night. I already did 2 other radios in the past with moode 6.x versions and they are working just great.
So, I most probably going to revert back to 6.4.2 as I promised a friend a moode music network player e/o next month.