Hello, I’m new here on the forum but not to Volumio. I enjoyed v1 for about one year before deciding to upgrade to v2 about a week ago.
With v1 I experienced some minor issues, none of them related to playback. Most of them have been addressed and solved in v2, but now I’m noticing an annoying general unresponsiveness (slow UI loading and reacting to commands) in my fresh setup, which seem to boil down to this: most of the time CPU activity spikes up to 100%. Right now I have no disk I/O activity, no playback, no library updating taking place, yet the web UI takes forever to load and the issued commands are executed after several minutes.
A quick peek to htop [spoiler][/spoiler]shows that the culprit may be a volumio/index.js process. Can anybody help me troubleshooting this?
My setup:
Cambridge Audio MagicDAC100
Raspberry B+
Volumio2
library folder on external usb mount (ext4 filesystem, I used to attach a ntfs drive but ntfs.3g was a serious cpu hogger).
edit: I usually connect to Volumio with my phone (via the Audioward or the Volumio Web UI apps) or from my laptop’s web browser, often from different devices simultaneously.
It’s node that is hogging the cpu, and that is normal after a fresh install, while it does various post-install tasks. This is especially noticable on the lower powered RPis such as version 1B. It should all settle down if you leave it running for 6-10 mins.
I installed about a week ago, and it has been running 24/7 as seedbox. Sorry I didn’t made that clear.
I just came home from work and checked the CPU load at rest: it was at an acceptable level. Now I queue a whole album and hit play: the first song plays normally, while CPU spikes at 100%; the queue is correctly populated, but all remote controls become unresponsive and playback doesn’t continue after first song ends.
So what’s /usr/local/bin/node doing? Why is this new setup short breathed?
Previous installation ran on the very same hardware, and it doesn’t seem like a matter of higher requirements.
Thank you both.
CPU is now idling during playback at 15-20% with 100% spikes at every track change and occasionally.
I think I’ll go with chsims1’s advice and clean install the thing all over again (I didn’t notice v 2.114 is out these days). Then I’ll report here and in case submit the logs.
By the way noticed a huge volumio.log file in /var/log/ , is that normal?
root@volumio:/home/volumio# ls -ahl /var/log/
total 75M
drwxr-xr-x 2 volumio adm 120 Mar 3 19:23 .
drwxr-xr-x 1 root root 4.0K Dec 12 00:15 ..
-rw-r--r-- 1 volumio volumio 1.5K Mar 4 16:19 albumart.log
-rw------- 1 root utmp 0 Mar 3 17:20 btmp
-rw-r--r-- 1 volumio volumio 75M Mar 4 16:34 volumio.log
-rw-rw-r-- 1 root utmp 6.4K Mar 4 16:12 wtmp
Nice nerdy saturday evening coming
edit:
Nevermind answering that, I’ve had my answer:
[code]CHANGELOG
2.114 (03-03-2017)
FIXES
[…]
Automatic clear log when more than 15MB in size[/code]
I did a fresh install of v2.114 and am now adapting the setup to my needs, checking carefully as I proceed. Volumio is playing flawlessy from the first minute (guys, this is awesome). CPU hogs only on track change (buffering?) and when accessing ntfs partitions.
Before I proceed I want point out one thing: apt-get update and apt-get upgrade are some of the first commands I use to run on a fresh linux install. From what I collect here and there in the forum this is somewhat discouraged. Do I understand correctly? Should I wipe it clean and start fresh again?
So, I started from scratch again with v2.114. Didn’t do apt-get upgrade, didn’t install anything new except htop and iotop. No ntfs mount, just ext3.
Still 100% cpu after 15min uptime. No indexing taking place, just playing tracks (which, on the other hand, play smoothly). GUI unresponsive.
What’s wrong?
Inviato dal mio D5803 utilizzando Tapatalk
edit: forgot to add htop screeshot:[spoiler][/spoiler]
edit2: could it be the remote interface? I’m using both “Volumio Web App” and Audioward on Android, have been using the former for a long time on Volumio 1, while the latter is a new entry for me.
After about 1 hour uptime cpu usage went down to an average 10%, but I’m noticing cpu spikes whenever I’m using the remote UI.
Followed the instructions to submit log, after hitting Send button in volumio.local/dev I wait forever and nothing happens. No “http://logs.volumio.org/xxxxxx” link appears after a 15 minutes wait.
I should add that while the issue happens, the UI is totally unresponsive, so any log I could submit via the dev interface wouldn’t likely be taken while the problem is actually taking place. I can ssh to the machine and successfully issue commands though, so do I have an alternative way to provide you with a log?
The last time the issue happened was after 20 min of idle uptime, not having played a track nor having received websocket connections since booting up. I took another htop screenshot via ssh then:[spoiler][/spoiler]
The time before was earlier today, I was playing a track and monitoring with htop via ssh, and CPU went 100% as soon as I connected to volumio with Audioward (android app). I rebooted and tried to replicate it (connecting with Audioward and other client apps), with no luck.
So, to sum it up:
v2.114 installed from scratch running on a rasp B+ (the same machine ran a v1.5 flawlessy), with music on local usb drive (ext3)
connection to mpd through the browser and (mostly) through two android apps, “Volumio webUI” and “Audioward”. The former gave no problems with v1.5, the latter I only tested with v2.114
CPU hogs at 100% under different and apparently unrelated conditions. Unable to replicate consistently the issue.
Issue may happen at startup, or after connecting to websocket, or with sistem idling, with or without playback activity. If it happens while playing a track, it will play smoothly until the end. Next track on playlist, if any, will not play instead.
While issue happens, the UI (browser/andoid app) is totally unresponsive. No log can be submitted during that time.
CPU goes down to reasonable level after considerably long amount of time, apparently without a triggering event. Playback would resume, as well as UI responsiveness.
It could be a client-related issue, but it wouldn’t explain this: last time the issue showed up, volumio had been freshly booted up and had been idling for 20 minutes. No connection to the daemon had been made, not even from the web interface.
I am following your hint for the time being, however, to see what happens
Been accessing Volumio through web browser and WebUI android app for a week, everything seems to run fine for now.
Maybe the culprit was the other app I was using.
[/spoiler]shows that the culprit may be a volumio/index.js process. Can anybody help me troubleshooting this?
[/spoiler]
[/spoiler]