12-31-2020, 08:48 PM
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.
(12-31-2020, 08:48 PM)Tim Curtis Wrote: [ -> ]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.
(12-31-2020, 08:00 PM)Alaini93 Wrote: [ -> ]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
(12-31-2020, 09:18 PM)vinnn Wrote: [ -> ]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?
(12-31-2020, 09:43 PM)fdealexa Wrote: [ -> ]Happy new year to everybody
(12-31-2020, 11:39 PM)TheOldPresbyope Wrote: [ -> ]@Alaini93Sorry forgot to add the tracks size, I have about 8500.
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