CPU on the NAS is jumping to 25%

Support
1

I wish to report a problem with playback in radio mode. When I put the system in radio mode, from time to time playback will just stop at the end of a track and the next track up for play by radio doesn’t start. What I see on the control device is the position marker is just sitting at the end of the just-played track. The play/pause button would shows it’s playing, but it’s not. If I hit the play/pause nothing happens. If I manually hit the button to jump to the next track, the next track starts playing and the system returns to normal. It’s annoying to have to “kick” the system back to life. Thoughts? @support

My Configuration:
Synology 3615 XS+ running Roon Core on SSD, 16GB of Memory
3 Bluesound Node2 Endpoints – all physically wired to router – no Wireless connection
Control of playback from iPhone and iPads
Netgear Nighthawk R9000 Router (X10)
Current SW/FW on all systems
Music Library = ~6500 Albums / ~90K Tracks, Redbook FLAC, HiRez FLAC, DxD and DSD
Active Tidal subscription with some Tidal albums added to library (<100 Tidal Albums in library)

2

Hi @c2c2c2 ---- Thank you for the report and sharing your feedback with us. We would like to see if we can reproduce this issue on our end and would like to gather a bit more information from you first :microscope:

May I kindly ask you to please verify the following information for me:

  1. Can you think of any patterns in behavior (procedurally speaking) that you may be noticing that could be influencing this experience?

  2. What tracks are we stopping on?

  • Local or TIDAL content?

  • Media type?

  • Sample rate?

  1. When you notice this stoppage in playback, is it to the same zone each time?

-Eric

3

Eric,

Thank you for the reply. Excellent questions.

  1. I’ve been looking for a pattern myself to no avail.

  2. At first I thought it was with Tidal content as that was the case the first time I observed the problem, then I noted the same behavior with local content so that theory didn’t hold up. I have not made note of sample rates and media types when this takes place, I will start keeping a journal and look for patterns. My local library is all FLAC (Redbook or above) or DSD (up to 512).

  3. It is not the same zone each time. I’ve also tried: a) using a different router; b) using a wireless connection versus the wired ones; c) seeing if grouping/ungrouping zones makes a difference (it doesn’t).

Thank you for investigating. If I get further data points from my own testing, I will add to this thread.

@support

1 Like
4

I have seen this once in the week I have toyed with my Node 2. I rarely use the radio function as I tend to listen to full albums most of the time – this happend when starting to play a new album while a different one was playing. Track counter appeared stuck at 0:00. Not sure about the bitrates, but most likely they were different.

Sometimes when switching albums, the Node 2 seems to need a few seconds to adjust before it starts playing.

Will keep an eye on this and report if anything related happens.

1 Like
5

Hi @c2c2c2 ---- Thank you for the feedback, as always, the insight is very appreciated.

We are going to see if we can find a way to reproduce this but if any new observations are made or you have any new feedback please due let us know.

-Eric

6

I have spent some time this weekend doing more controlled testing in an attempt to provide more insight to this problem. It appears the problem is not restricted to the use of the radio function. This weekend’s testing managed to consistently demonstrate the issue and the radio function remained off throughout.

Here is more detail on my test scenario:

The Testing Scenario

Two Zones Grouped (all wired Gb connections). The third Node2 was left inactive and out of the testing to eliminate variables.

Each device in the zone has some unique settings applied. This reflects my normal listening config so I left it unchanged. I am including screen shots for each of these two zones so you may see the signal chain. One of these zones is for my headphones, the other for the primary listening room – see screen shots below for DSP settings for each zone.

Both devices are set to playback at 192K/24. This is the maximum resolution of the Node2 and Roon upsamples/downsamples/converts to hit this level as required.

I have created a queue that mixes up formats & sample rates ranging from Redbook to DSD256. All PCM is in FLAC.

When operating normally, the CPU use on the NAS for Roon is typically <3%. Additionally, during this testing my NAS was doing nothing else so the CPU was mostly idle, I/O was minimal, and memory was mostly free. This is typical for this NAS which has capacity well in excess of its use.

One interesting observation, when the system gets “stuck,” the CPU use for Roon on the NAS jumps to about 25% and remains there until I “bump” Roon from a control until onto the next track, at which point the NAS returns to normal. Additionally, I have noted that in some cases, not all, the control on the iPad will display the error message: “Transport: Roon has lost control of the audio device.”

There does not seem to be a pattern of switching resolutions when a new file comes up in the queue and this issue.

2017-05-07 17.19.54.png2048×1536 994 KB

2017-05-07 17.20.14.png2048×1536 1000 KB

My Configuration:
Synology 3615 XS+ running Roon Core on SSD, 16GB of Memory
3 Bluesound Node2 Endpoints – all physically wired to router – no Wireless connection
Control of playback from iPhone and iPads
Netgear Nighthawk R9000 Router (X10)
Current SW/FW on all systems
Music Library = ~6500 Albums / ~90K Tracks, Redbook FLAC, HiRez FLAC, DxD and DSD
Active Tidal subscription with some Tidal albums added to library (<100 Tidal Albums in library)

@support

7

Hi @c2c2c2 ----- Thank you for the follow up and providing us the results of the testing you’ve conducted, the insight is always very appreciated.

Moving forward, can you replicate this behavior, note the time when the CPU usage jumps, and then provide us a set of Roon logs. We’d like to take a closer look at what could be going on here.

-Eric

8

@Eric, @support

As you requested, I have conducted an additional series of test as outlined below.

Review of Testbed:

Two Zones Grouped (all wired Gb connections and Bluesound Node 2 endpoints). The third Node2 was left inactive and out of the testing to eliminate variables.

Each device in the zone has some unique settings applied. See above for details.

Both devices are set to playback at 192K/24. This is the maximum resolution of the Node2 and Roon upsamples/downsamples/converts to hit this level as required.

Logs from testing scenarios are in folders corresponding to these instances:

These first set of logs all demonstrated a consistent failure when the current track changed from a lower resolution track (Redbook 44/16) to a higher resolution one.

Instance #1: In “Playing Artist” mode in two grouped zones, playback stopped at the end of Redbook track. Roon server was then manually stopped and logs captured.

Instance #2: In “Playing Artist” mode in two grouped zones, playback stopped at the end of 96/24 track, next track up was 192/24. Roon server was then manually stopped and logs captured.

Instance #3: In “Playing Artist” mode in two grouped zones, playback stopped at the end of Redbook, next track up was 192/24. Next track was started by: first hitting the “Next” button on Roon control, then hitting the “Play” button. Note that the control application displayed the message: “Transport: Roon lost control of the audio device.” Server was not stopped, logs copied after next track had started.

Instance #4: In “Playing Artist” mode in two grouped zones, playback stopped at the end of Redbook, next track up was 192/24. Next track was started by: first hitting the “Next” button on Roon control, then hitting the “Play” button. Note that the control application displayed the message: “Transport: Roon lost control of the audio device” after hitting the play button the first time. Hitting the play button a second time started the music. Server was not stopped, logs copied after next track had started.

Up to this point in testing, it appears that whenever going from Redbook to a 192/24 track, the system hangs. BUT THERE’S MORE….

Instance #5: For this next test, I play a single album (same artist) that is 192/24 to the same grouped zones. The album is set to play start to finish in track order and no radio function. In this case, the album played all tracks, however, when it reached the end of the album something curious happened. The control unit shows it is still playing (see image) and the NAS has spiked with 25% going to Roon, but nothing is happening. I hit manual pause on the control and Roon use on the server falls no nothing(ish).

2017-05-13_10-10-23.jpg1280×1440 169 KB

Instance #6: Next, I tried running the same instances/scenarios used in 1-4 but I ungrouped the zones. I ran the same tests on a single zone and the problem changed. The system lost control of the zone mid-way through playing a 192/24 track. I left server running and captured logs. The zone disappeared from Roon then reappeared about a minute later with no action on my part. Hitting play resumed playback.

Rather than continue to make up scenarios, I will wait for feedback on these logs to see where we go from here.

Thank you in advance for your support.

P.S. I have the logs in a single zip file, but I can’t seem to attach to this post. How best to send you the logs?

1 Like
9

Logs have been uploaded.

10

Awesome, thanks John (@c2c2c2)! Confirming that they have been received and are in our queue to be evaluated. We’ll let you know what we come up with.

-Eric

11

Thank you.

1 Like
12

@Eric,

Any progress? If it helps, I can also provide the diagnostic logs from the Bluesound Node 2. Not logs that coincide with the specific incidents documented above but that cover other similar incidents of stopped playback and Bluesound distress.

The Blusound logs are quite verbose and much of it looks like normal status messaging. I do however note multiple warning messages as such:

May 19 01:37:37 (none) user.info dspout: [warning] dropout of 2048 samples at 43967 [2]
May 19 01:37:37 (none) user.info dspout: [warning] dropout of 2048 samples at 46015 [2]
May 19 01:37:37 (none) user.info dspout: [warning] dropout of 2048 samples at 48063 [2]

And then…

May 19 03:54:53 (none) user.info dspout: [warning] dropout of 2048 samples at 47083 [2]
May 19 03:54:53 (none) user.info dspout: [warning] dropout of 2048 samples at 49131 [2]
May 19 03:54:53 (none) user.info dspout: [warning] dropout of 2048 samples at 51179 [2]
May 19 03:54:53 (none) user.info dspout: Command(l=5): I5000
May 19 03:54:53 (none) user.info dspout: [warning] dropout of 2048 samples at 53227 [2]
May 19 03:54:54 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action
May 19 03:57:31 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action?service=Raat¬ify=pause
May 19 03:57:31 (none) user.info ./ms.pl: Controller::pause Controller.pm (1604) pause
May 19 03:57:31 (none) user.info dspout: Command(l=1): P
May 19 03:57:31 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action
May 19 03:57:31 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action
May 19 03:57:31 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action
May 19 03:57:31 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action
May 19 03:57:31 (none) user.info dspout: Command(l=5): I5000
May 19 03:57:31 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action
May 19 03:57:33 (none) user.info ./ms.pl: main::HttpRequest ./ms.pl (901) [1] 127.0.0.1: /Action?service=Raat¬ify=play&stream=0x1b52f60&samplecapacity=960000&streamsample=0&starttime=1495166252957627863
May 19 03:57:33 (none) user.info ./ms.pl: Controller::resumeRaat Controller.pm (1651) resumeRaat
May 19 03:57:33 (none) user.info dspout: Command(l=50): R166253105

As a reminder, these are wired nodes - Cat 6A, on a top-of-the-line router with Jumbo Packets disabled and no other traffic at the time of the testing. This issue occurs on multiple ports and on different cable runs. Also, I’ve tried the testing using a different router and the problem persists. I’ve tried to eliminate every variable I can.

Thanks.

13

@Eric:

Some further information on this Bluesound problem: In addition to Roon (here), I also contacted Bluesound support and sent them the full Bluesound logs. Here is an excerpt from one of their replies:

“We can see that the Players are freezing and rebooting around when a song is initiated through Roon, is this always the same song or does this happen with seemingly any song?”

As answered above, it can be any song/format.

As you can see, Roon is causing the players to freeze/reboot. I will restate that this does not happen when playing with BlueOS.

As a customer, this puts me somewhat in the middle… is it Roon or Bluesound that takes the lead in resolving this issue? Please help.

@support

14

Hi @c2c2c2 — Thank you for the continued feedback and more importantly your patience. My apologies for the sow response.

I had a chance to meet with a few of my team members today and we are going to try to reproduce this behavior on our end to try and determine it’s cause. My report (and your logs) have been added to our testing queue and once our tech team has completed their analysis/investigation I will be sure to follow up promptly with their thoughts/findings.

-Eric

15

@Eric,

Thank you for the update. I look forward to hearing your findings. Let me know if you want the logs from the Bluesound which show the unit crashing and rebooting.

Best.

@support

1 Like
16

@Eric,

Some additional information. In addition to reporting this issue here, I reported it to Bluesound as I was not sure who was responsible for working through to resolution. After sharing logs with them, they sent me the following:

Thank you for that information.

As this is only happening with Roon we recommend you reach out to Roon as they have informed us they would like to deal with all Roon related issues.
We did see from the log file that there are many network dropouts related to specifically Roon so there may be an issue in the network connection of the Players or Roon Core.

You can reach out to Roon here ; I'm having a problem with Roon -- where do I report it? OR here ; https://roonlabs.com/contact.html

Brandon C
BluOS Support Crew Analyst

As he mentions here and as I’ve previously detailed, this only happens when playing through Roon. I can play all day long with the same songs using the Bluesound app and there are no issues and the logs are clean.

@support

1 Like
19

Hi @c2c2c2 ---- Thank you for your patience here, as always, very appreciated!

I wanted to touch base with you because we have done some work for our next build release that we believe could possible improve this behavior your are experiencing. When the next build goes live, may I very kindly ask you to please touch base with us via this thread and confirm if things are better, worse, or have stayed the same.

I will be on the look out for your feedback :sunglasses:
-Eric

20

@Eric,

Great! I am ready to start testing! I appreciate the work and update. Also, please note that I’ve filed an additional report related to “clicks and pops” which I suspect may be ultimately related to the same issue. It can be found here.

Have a great holiday weekend!

Cheers.

21

@Eric,

Will this be coming soon? These issues are frequent enough that I’ve not been using Roon and rather have reverted to playing just through BlueOS directly, which works fine.

22

Hi @c2c2c2 ---- Just touching base with you, as the update has gone live, to see how things are holding up. Looking forward to your feedback!

-Eric