Temp and cpu util have never really been support vectors for moOde so my thought was to thrift those items from Audio Config and improve its responsiveness. It displays instantly now 🙂
I think if system is bogged down then utils like TOP or PS <args> would be the way to go to try and isolate the process thats hogging the cpu.
-Tim
Ok you answered my post as well.
You haven't got an ip access rules have you?
The console on freenas often helps here.
Erm freenas pingable ? 🙂
Sent from my P01M using Tapatalk
Will top and ps work from a locally attached display...?
Otherwise it becomes even longer-winded to access....
Boot another device...open an ssh instance...etc etc....
What about a dedicated cpu/temp tab..?
Otherwise it becomes even longer-winded to access....
Boot another device...open an ssh instance...etc etc....
What about a dedicated cpu/temp tab..?
moOde build on small memory RPis
Hi, Tim et al.
I have long since donated my early generation RPis so my RPi0W is the smallest memory RPi I have (512MB).
I ran mosbuild.sh on a linux host and accepted all the optional components. Plugged the resulting uSD card into the RPi0W, connected the RPi0W to a wired ethernet port on my router, and booted. I then ssh'ed into it (repeatedly of course) and continuously ran top as a crude way to watch memory usage (since it samples only every n seconds where I accepted the default n=1.5).
As expected, the moOde 4.0 build succeeded.
Creating Libupnp turned out to be the memory-hogging step. The reported total memory is 44416KiB and available memory dropped to a low of about 178000KiB in this step. This means a peak of about 266526KiB was used. That's more memory than contained in a 256MB RPi so I would expect the build to out-of-memory (OOM) fail on such devices unless swap space were available. [but see caveat below]
I then rebooted and installed the optional gmusicapi component. I watched available memory dip to as low as 1208KiB while pip was setting up the wheel for lxml and blam-mo this step failed with an ugly traceback which basically meant OOM. So swap space (or the hack I mentioned earlier of using precompiled lxml) is needed here too, even on the 512MB RPi0W.
The one caveat I have regarding Libupnp is that I did not try reducing the gpu_memory allocation setting via boot/config.txt. The default setting is 64MB (which is why my available memory was reported to be only 444516KiB) and the minimum possible setting is 16MB. Perhaps setting it to the minimum to reclaim 48MB could make the difference in building moOde 4.0 on a 256MB RPi. Perhaps setting it to the minimum would also cause something else to break (as intimated in the Rapberry Pi Blog). I didn't have time today to explore it.
Regards,
Kent
Hi, Tim et al.
I have long since donated my early generation RPis so my RPi0W is the smallest memory RPi I have (512MB).
I ran mosbuild.sh on a linux host and accepted all the optional components. Plugged the resulting uSD card into the RPi0W, connected the RPi0W to a wired ethernet port on my router, and booted. I then ssh'ed into it (repeatedly of course) and continuously ran top as a crude way to watch memory usage (since it samples only every n seconds where I accepted the default n=1.5).
As expected, the moOde 4.0 build succeeded.
Creating Libupnp turned out to be the memory-hogging step. The reported total memory is 44416KiB and available memory dropped to a low of about 178000KiB in this step. This means a peak of about 266526KiB was used. That's more memory than contained in a 256MB RPi so I would expect the build to out-of-memory (OOM) fail on such devices unless swap space were available. [but see caveat below]
I then rebooted and installed the optional gmusicapi component. I watched available memory dip to as low as 1208KiB while pip was setting up the wheel for lxml and blam-mo this step failed with an ugly traceback which basically meant OOM. So swap space (or the hack I mentioned earlier of using precompiled lxml) is needed here too, even on the 512MB RPi0W.
The one caveat I have regarding Libupnp is that I did not try reducing the gpu_memory allocation setting via boot/config.txt. The default setting is 64MB (which is why my available memory was reported to be only 444516KiB) and the minimum possible setting is 16MB. Perhaps setting it to the minimum to reclaim 48MB could make the difference in building moOde 4.0 on a 256MB RPi. Perhaps setting it to the minimum would also cause something else to break (as intimated in the Rapberry Pi Blog). I didn't have time today to explore it.
Regards,
Kent
It's a tuning feedback. Change something and get an instant indication of the general performance hit or improvement.
When there's no change then you know to go hunting further...ssh and top, ps, etc.
Most times we know or guess educatedly the parameter we change in the UI... having quick feedback tells us we are on the right track or not..
Saves us bothering you for more in depth solves if it is a footling fix we can do ourselves.... just need that feedback...😀
While I'm writing this, the script is being run one more time without the swap removal lines.
I have a modified copy of mosbuild_worker.sh in which I've also disabled downloading of the file from Tim's server.
In hindsight I should have reduced the graphics memory to minimum as well, but nevertheless.. I'll report back what I observe. And if this one fails, I'll try one more with the reduced graphics mem.
This is on a 256MB RPI B (the original one) with Samsung 16GB EVO card. Here is what free looks like
pi@moode:~ $ free -m
total used free shared buff/cache available
Mem: 180 36 31 1 112 92
Swap: 99 1 98
I have a modified copy of mosbuild_worker.sh in which I've also disabled downloading of the file from Tim's server.
In hindsight I should have reduced the graphics memory to minimum as well, but nevertheless.. I'll report back what I observe. And if this one fails, I'll try one more with the reduced graphics mem.
This is on a 256MB RPI B (the original one) with Samsung 16GB EVO card. Here is what free looks like
pi@moode:~ $ free -m
total used free shared buff/cache available
Mem: 180 36 31 1 112 92
Swap: 99 1 98
Yes, as headless then reducing graphics memory to minimum makes sense.
For reference...
ssh in and run
Code:
raspi-configThe context of your original post was cpu hogged due to SSH install of a Python script. You can use TOP or PS <args> to troubleshoot in this case.
I built another image with another microsd card. Everything works fine until I enable the display option. The display will come up but then when I reboot the display fails to come on and the image is non-usable.
Moode 4 beta 12 works fine and is what I am continuing to use until I can get the display functional.
Last edited:
RPI3 automated install... less than an hour 😀
pi@moode:~ $ moslog
** Clean package cache
** Clear syslogs
** Sat 3 Feb 05:08:05 UTC 2018
** Installation time : 00:59:42
////////////////////////////////////////////////////////////////
// END
////////////////////////////////////////////////////////////////
** Final reboot
pi@moode:~ $ moslog
** Clean package cache
** Clear syslogs
** Sat 3 Feb 05:08:05 UTC 2018
** Installation time : 00:59:42
////////////////////////////////////////////////////////////////
// END
////////////////////////////////////////////////////////////////
** Final reboot
No access rules, as I mentioned everything the same except version of moode. When I swap to the sd card with 3.8 it mounts to the nas without issue (utilizing the same IP address)
Now that the 4.0 is out, I plan to upgrade only due to the new feature around BlueTooth.
So, when I look at the instructions on moode.org, I see that the Raspbian file is just 18 MB.
On the other hand @drone7 has in this post provided instructions where he/she has pointed to a Rasbian with 348 MB.
The 18 MB zip does not seem to have an image file. It is just a bunch of folders.
What am I missing?
So, when I look at the instructions on moode.org, I see that the Raspbian file is just 18 MB.
On the other hand @drone7 has in this post provided instructions where he/she has pointed to a Rasbian with 348 MB.
The 18 MB zip does not seem to have an image file. It is just a bunch of folders.
What am I missing?
spontaneity! just do it... there are only two so try one and if that doesn't work try the other....😉
looks like you've worked it out already.... the download of Raspian-stretch-lite is an os that you then build MoOde on....it is hardly likely to be 18MB... but check the size at the raspberry pi downloads page....Download Raspbian for Raspberry Pi
Main reason about not using swap on RPI :
- IO is reducing SD life so if you don’t really need swap, don’t use it 😀
But it looks like we need it on old models ( just to build moOde !).
I agree about moving this step at the end of the script but maybe we can just add a test to preserve swap on Model 1 or even based on memory detection before removing it ( or desactivating it )
This will be quite easy to code.
Just my 2 cents
-Eric
My PI3 made it in less then 50min.
** Clean package cache
** Clear syslogs
** Wed 31 Jan 19:53:23 UTC 2018
** Installation time : 00:48:33
////////////////////////////////////////////////////////////////
// END
////////////////////////////////////////////////////////////////
** Final reboot
** Clean package cache
** Clear syslogs
** Wed 31 Jan 19:53:23 UTC 2018
** Installation time : 00:48:33
////////////////////////////////////////////////////////////////
// END
////////////////////////////////////////////////////////////////
** Final reboot
My observations / experience.
I removed the 3 lines for deleting swap from the worker file and reduced the graphics mem to 16M in config.txt
I had a successful build in 02:58:37 (now building the library from a NAS), which to me is quite acceptable rather than failing. I tried building 4-5 times before this, none of them succeeded.
So swap *is needed* for the build on 1st generation PIs, but not for run-time. This however, may not be a significant use case but it's up to Tim & you guys.
Also, mpd/nginx/php/watchdog were running while the optional components were being built. Suggest that the daemons don't start until the very end of the build script.
I removed the 3 lines for deleting swap from the worker file and reduced the graphics mem to 16M in config.txt
I had a successful build in 02:58:37 (now building the library from a NAS), which to me is quite acceptable rather than failing. I tried building 4-5 times before this, none of them succeeded.
So swap *is needed* for the build on 1st generation PIs, but not for run-time. This however, may not be a significant use case but it's up to Tim & you guys.
Also, mpd/nginx/php/watchdog were running while the optional components were being built. Suggest that the daemons don't start until the very end of the build script.
Last edited:
Weird just worked for me and i am being naughty and publishing a ro nfs mount of an smb share.
Can you post or pm me your your settings in Freenas for the nfs service and your nfs share.
Regards
Sent from my P01M using Tapatalk