12-31-2020, 11:39 PM
@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
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
