Radio mode playback issue

Hi, I’ve been experiencing a playback issue which you may not be aware of:

Intel NUC 7i7BNH
WD DUO 6 TB USB 3 drive configured as a 3 TB RAID mirror as the mudic store
Roon OS Version 1.0 (build 153) stable
Roon Software Version 1.4 (build 294) stable
19786 tracks, 1544 albums

Audio endpoint
Meridian 218

The problem. I generally play an album or more when listening, but inevitably end up in radio mode for an amount of time before ending a listening session for the day. The NUC is left on overnight.

When resuming listening the following day, I usually hit the play button to resume where I left off. This is where things go awry; the server or software quite often reboots, or marks a series of tracks corrupt and refuses to play them. This condition persists across an application or server reboot.

The only thing that seems to clear this is the playing of an album, after which radio mode is happy to play continuously for hours.

This problem was apparent in the previous version of software which was updated on the weekend just passed.

Given the library size, should I be increasing the RAM to 8 GB? Is there anything else I should do to prevent re-occurrence?



Hi Dennis,

I think it’s unlikely that RAM is the problem so I’d suggest not adding any unless Support indicates that it is the issue.

Support will be along shortly and may be able to identify the issue by looking at logs from your system when this unusual state is occurring.

@support will help this along :smiley:

Hi @Dennis_Carter ---- Thank you for the report and sharing this observation you have made with us. The insight is very appreciated and my apologies for the wait here.

Moving forward, I would like to enable diagnostics on your account so our techs can try to get a sense as to what could be causing this behavior with your setup but before I do may I very kindly ask you to please perform the following:

  • If you have note already, please update all of your Roon devices to the last build (i.e. Build 298) and verify that you are still experiencing this behavior.

    If you are still having the issue…

  • Please reproduce the issue and note the time when you notice the error.

“When resuming listening the following day, I usually hit the play button to resume where I left off. This is where things go awry; the server or software quite often reboots, or marks a series of tracks corrupt and refuses to play them. This condition persists across an application or server reboot.”

  • Next please note the time when the system stabilizes by using the mentioned work around.

“The only thing that seems to clear this is the playing of an album, after which radio mode is happy to play continuously for hours.”

Once I have the requested time frames from above I will flip on the mentioned diagnostics as this action will automatically generate/upload a diagnostics report containing a set of Roon logs directly to our servers.


Hi Eric,

Here’s where I’ve got to:

Problem re-occurred at 0620 Jan 25th. Playing started, but then stopped after less than 30 s and playlist shifted to the next track but did not re-commence playing. Invoking a ‘play from here’ on the original track selected appears to resolve everything.

Logged the same issue again at 1751 on the 25th. Same outcome.

Logged the same issue again at 0623 on the 26th. Same outcome.

Logged the same issue again at 1613 on the 26th. Reverted to the earlier behaviour i.e. prior to the software update, and I had to play an album to get things straight again.

Hope that helps,


Hi Eric,

So this morning, rather than muck about with the issue, I did the following:

  1. Started by rebooting the NUC
  2. Played an album which was flawless, with radio mode set to start at the end
  3. At the end of the album the first radio track was queued, but didn’t start to play automatically
  4. The next track started to play, then play was interrupted by an autonomous NUC reboot i.e. it did it itself with no input ftom me
  5. Once back up, Roon marked the then playing track as corrupt and moved to the next track which it didn’t automatically start to play
  6. Playing that track caused the software to mark that track and the next three tracks as corrupt with the error message ‘Transport stopping play, too many failures’

I was concerned that I might have had a hardware issue with the hardware purchased for this sole purpose, but given that albums appear to play flawlessly, I don’t see how that can be the case.

I hope this helps with the diagnosis,


Hi Eric,

After my last, I went back to playing albums, and I’ve just had another self induced reboot at 1019. Could this be a hardware problem after all?



Hi @Dennis_Carter ----- Thank you very much for following up with me and providing the requested feedback. Very appreciated!

Moving forward, I enabled the mentioned diagnostics on your account and the report came in almost immediately. I am going to be attaching the received report to your ticket and then passing everything over to our techs for further analysis. Once they have completed their evaluation I will be sure to share their thoughts.findings with you ASAP.


Hi Eric,

Just an update while you have logging enabled:

Jan 29. Started play at 06222. The track started then stopped. The iOS app lost contact with the server for about 10 s. Once recovered, invoking play did in fact allow things to proceed as normal. As can be seen from previous reports, this behaviour is very different to that normally experienced. Play was paused around 0640. At 0700 ad part of my prep for heading to work, I tried to mute the system, and couldn’t. None of the controls in the iOS app worked other than select audio zone; this was fixed by quitting and restarting the app.

I’ll report what happens this evening…



Hi Eric,

Update from the evening:

Jan 29 1914. Starting of play caused current track in play to be aborted within 20 s. Follow on track marked as corrupt and play not started. When play was invoked, track played perfectly and follow on tracks played without incident.


Hi @Dennis_Carter ---- Thank you for your continued feedback while our techs have been looking into this behavior.

Moving forward, as per the team’s update they are not seeing anything conclusive in the log traces pointing to the cause of this behavior with your setup and in light of this have asked if you could provide us with the details of your network configuration/topology.

Additionally, if I am not mistaken (do correct me if I am wrong :innocent: ) your musical collection is currently being hosted on the mentioned 6TB WD USB 3 drive, correct? By chance during your troubleshooting have you tried moving some media to the local storage of the NUC and confirming what the behavior is like? If you have not may I kindly ask you to please try the following and let us know that the experience is like (see below).

  • Temporarily disable your current watch folder(s) in Roon (i.e anything looking at the WD HD).

  • Move 10 - 20 albums to the internal storage of the NUC.

  • Try to reproduce the issue with albums stored on the NUC.


Hi Eric,

Yes the music storage is the attached USB drive set up as a RAID mirror, so in effect a 3 TB drive.the reason its set up this way is that these drives will fail, and I didn’t want the hassle of having to copy the whole music library from the ripping station (Mac Mini with Netgear NAS) onto a replacement drive. This way if one drive fails, I can replace it and the RAID software will sort things out.

The NUC is attached to an unmanaged Ethernet switch, as is the Meridian 218, Apple TV, Roadrunner Networked DVB tuner, TV, Blu-Ray player, Meridian MC200 (not in use) and importantly the main broadband connection to the house a 4G modem. The other side of the switch goes to another Ethernet switch to which is attached a Mac Mini, Nethear NAS, laptop docking station, HP printer and WiFi base station. In essence the network looks like 2 Ethernet hubs connnected back to back with a fan out at each end.

As I reported earlier, when you enabled the logging, the system behaviour has changed quite dramatically in that I’m no longer seeing the behaviour as originally stated.

I haven’t tried moving some music files onto the internal storage, but I can do that if you need me to.plesae let me know, and I’ll get to that some time tonight.

Hope that helps,


1 Like

Thanks for getting back to me @Dennis_Carter, very appreciated!

I was actually editing my post when you responded so my previous post has been updated with the steps for the proposed test for using the internal storage of the NUC :microscope:

Looking forward to hearing your observations!

Hi Eric,

Just tried to access the NUC over the local network, and the main library access is denied to me. I can get to a directory /Data/Storage , and inside is a locked directory /Data/Storage/Roon_Store_WD_My_Book_Duo(plus a long string of digits). I’m pretty sure the drive carries the title Roon Store.


This image shows what I can see. Prior to this, I could access the drive and drop music onto it for the server software pick up. Is this part of the problem, or something else?



Hello @Dennis_Carter,

To get access to current drive you need to mount Data folder using CIFS. Here is how you can do this:

  1. Open Finder
  2. Unmount current Data folder by pressing the Eject button in front of its name
  3. Press Comman+K to open Connect to server window
  4. Enter path to the data folder in the following way cifs://ROCK_ip/data
    19 AM
  5. Select Guest access in appeared menu
  6. Press Connect once more
  7. Try to open your external drive
1 Like

Hi Vova,

Thanks for the input. That gets me back in and allows me to proceed with testing. I have two other issues as a result:

  1. The instructions in your video explicitly show access to the ROCK using smb (, which is clearly problematic as your instruction to use cifs proves. Can I suggest that your video be updated?

  2. I tried to do a bulk copy of a few hundred albums from the external USB drive onto the internal SSD, and found most of what I wanted to copy I couldn’t with a reported error being a lack of Read privileges. This clearly can’t be right as this directory was created with the drive connected directly to my Mac and the bulk of the files copied from a NAS onto the drive before it was attached to the NUC. Part of the problem I’m experiencing might be caused by access privilege changes. Is there any easy way to confirm and correct this without having to attach a keyboard and monitor to the NUC?

I’ll report back on the original Radio functionality problem in a day or so after I’ve done the necessary testing.



^Hi Folks,

After one long paused session, media stored on the internal drive appears to have completely cleared any issues with Radio mode. I’ll continue to report back on progress over the next few days to confirm that this situation continues.

Update from 2029 February 1. No problems encountered with Radio mode playing from the internal drive after a 14 hour pause. Just thinking about this, could the issue be caused by the interface to the external drive? The drive is currently connected via Thunderbolt; would a connection via USB 2 behave differently?

Update from 0702 February 2nd. No issues encountered. Paused track played perfectly, subsequent follow on tracks played perfectly.

Update from 1702 February 2nd. No issues encountered. Paused track played perfectly, subsequent follow on tracks played perfectly.



Hi @Dennis_Carter ----- Thank you for touching base and sharing your observations after performing the proposed troubleshooting exercise. Very please to hear that is yielded a positive result!

Moving forward, the connection “type” should not have an affect on performance, however if there is an issue with the thunderbolt cable itself I can see that causing an issue. Would you kindly try using the USB2 interface and let me know if the issue reoccurs. Many thanks!


Hi Eric,

I’ll do that and report back. FYI at 0843 on February 3rd, I was streaming in Radio mode to an iPad, and the playing track stopped part way through and play skipped to the next track. I went back and started the play from this track and it then played flawlessly.

2055 on February 3rd. Switched back to external WD Duo drive as storage and after a 1 hour pause, the track played for less than 30 seconds, then moved onto the next track but did not play it. Invoking ‘play from here’ for the track that was switched from allowed things to operate normally.

2247 on February 3rd. First Radio mode track after playing an album stopped 10% in, stopped, and the next track was selected but not played. Invoking ‘play from here’ on the interrupted track allowed things to proceed normally.

0753 on February 4th. First radio track after pause played flawlessly. The next track started to play, then stopped after 5 seconds. Invoking play allowed things to proceed normally.

2147 on February 5th. Play from a 36+ hour pause caused the selected track to stop after less than 20 seconds. The playlist switched to the next track which didn’t start to play. Invoking play from here on the track that was interrupted allowed play to resume normally.

0633 on February 6th. Play from pause stopped after 10 s. The iOS app appeared to temporarily lose contact with the server. Invoking play allowed things to proceed normally.

1821 on February 6th. Play from pause stopped after 10 s. The iOS app appeared to temporarily lose contact with the server. Invoking play allowed things to proceed normally.

0630 on February 7th. Having discussed the issue with a friend last night, he suggested that the external WD drive might have a sleep setting; I checked, it did and was set to 30 minutes and I disabled it straightaway. Play from pause worked perfectly. I feel I must apologise for squandering your resources investigating what would appear to be a system setting in this configuration.

Please could you disable your logging mechanism so that I can be sure that the the orginal reported problem has been cleared? The next time I’ll be able to give a status update is around 1900 on February 8th.

1844 on February 8th, test before software update. Play from pause worked flawlessly.

0622 on February 9th. Play from pause worked flawlessly.

0905 on February 10th. Play from pause works flawlessly every time. Unless requested, this will be the last status update.