Official moOde 7.0.1 support thread

[Tim Curtis]

IIRC you have some hardware connected to the Pi and other software installed. You need to specify your exact config so someone with that exact config or similar can try to repro.

[Alaini93]

IIRC you have some hardware connected to the Pi and other software installed. You need to specify your exact config so someone with that exact config or similar can try to repro.

There is only a HDMI 3.5 screen Kuman TFT Touch Screen, but don't use the touch (didn't set up any driver for it).
It's because of it, what everything is happening I think, Chromium eats all the memory because I set the Local display ON.
I have other scree and button but not set up on this sdcard.

[vinnn]

Hi,

 Here what I get after power it on this morning, didn't play any song, just left it on with "top" running to monitor.
Of course now it's stuck, cannot access UI from anywhere, and SSH is stuck too.

If it's something that nobody wants to look at, you need to tell me, I will stay with 6.7.1

My guess is that the local web browser (chromium) is bogging down the Pi's SD card and exhausting the Pi's available memory, in your screenshot the three chromium processes are using 80% of the Pi's memory, has mapped about 2GB of Linux virtual memory and the system load average is around 21.
Disable the local display option and see how it goes.

Curious, how many tracks do you have in your library?

[Alaini93]

My guess is that the local web browser (chromium) is bogging down the Pi's SD card and exhausting the Pi's available memory, in your screenshot the three chromium processes are using 80% of the Pi's memory, has mapped about 2GB of Linux virtual memory and the system load average is around 21.
Disable the local display option and see how it goes.

Curious, how many tracks do you have in your library?

Hi Vinn,
Yes, If I disable the screen with "Local UI display" OFF, chromium is not showing in top, so it will work, I try it before.

I didn't setup Moode 7 differently than 6, there is no reason why it should not work, unless somebody change something in the code and didn't tell his friends.

[fdealexa]

Happy new year to everybody

[TheOldPresbyope]

@Alaini93 

Yes, things changed between 6.7.1 and 7.0.1. Nothing mysterious---all identified in the release notes.

The Kuman display is just an HDMI display; nothing special there. I have one too. What happens with a local display is that what is normally transferred to buffers in the browser on another device is also loaded into buffers of the chromium processes running on the moOde player.

You didn't answer Vinnn's question, how many tracks are in your library. The more the tracks the bigger the payload.

I'm running moOde 7.0.1 on an RPi3B+ just now with a Kuman 3.5" HDMI local display. I've mounted a library containing ca 6000 tracks.


The top command shows the CPUs are 92 percent idle; there's 632MB of available memory. The chromium process most hogging the host is consuming only 15 percent CPU and 14 percent memory. The swap daemon kswapd0 is nowhere in sight.

The first top image you posted, on the other hand, shows your RPi3B+ is figuratively gasping for air. The CPUs are 97.5 percent in the wait state (associated with trying to swap); there's only 8MB of available memory. The kswapd0 process is running and one of the chromium process is consuming tons of memory.

I'm very suspicious this is due to an unfortunate collision between 1) the size of your library 2) the change in the way information is being passed to the browser. If you have an RPi4B/2GB or /4GB board on hand, it would be interesting to know if the issue goes away on them.

Regards,
Kent

[Tim Curtis]

One of the earlier posts showed moOde LCD updater engine is running but I thought @Alaini93 was using @adrii's nice LCD updater code ??

20201230 101736 worker: LCD updater engine started

[Tim Curtis]

Happy new year to everybody

Likewise, Happy New Year to all :-)

[Alaini93]

Happy new year to everybody

Likewise, Happy New Year to all :-)

Thanks, Happy new year Everyone!

[Alaini93]

@Alaini93 

Yes, things changed between 6.7.1 and 7.0.1. Nothing mysterious---all identified in the release notes.

The Kuman display is just an HDMI display; nothing special there. I have one too. What happens with a local display is that what is normally transferred to buffers in the browser on another device is also loaded into buffers of the chromium processes running on the moOde player.

You didn't answer Vinnn's question, how many tracks are in your library. The more the tracks the bigger the payload.

I'm running moOde 7.0.1 on an RPi3B+ just now with a Kuman 3.5" HDMI local display. I've mounted a library containing ca 6000 tracks.


The top command shows the CPUs are 92 percent idle; there's 632MB of available memory. The chromium process most hogging the host is consuming only 15 percent CPU and 14 percent memory. The swap daemon kswapd0 is nowhere in sight.

The first top image you posted, on the other hand, shows your RPi3B+ is figuratively gasping for air. The CPUs are 97.5 percent in the wait state (associated with trying to swap); there's only 8MB of available memory. The kswapd0 process is running and one of the chromium process is consuming tons of memory.

I'm very suspicious this is due to an unfortunate collision between 1) the size of your library 2) the change in the way information is being passed to the browser. If you have an RPi4B/2GB or /4GB board on hand, it would be interesting to know if the issue goes away on them.

Regards,
Kent

Sorry forgot to add the tracks size, I have about 8500.
So you are telling me I should get a RPi4 to run 7? 
For now I will turn it off when not in use, because it's working fine while playing, chromium stays down to 15%, it just get crazy when not playing
And no problem with 6.7.1.