Linux Roon server not playing high res files to Squeezebox [Fixed in 1.3]

Well, the OP pretty well sums it up.

Basically, there were four types of failure noted.

  1. High res playback failed after a variable period of time when playing from the Linux RoonServer to the Squeeze endpoint. This is the central issue, as far as I’m concerned. It almost felt like it could be related to something that gets cleaned up by the overnight cron jobs. The “first” session of a given day would play longer before failing than subsequent attempts. After one failure to noise, an attempt to play a track would only last a minute or so. As far as I can tell, there were no events associated with when the stream failed.

  2. The “limit sample rate” dialog in Roon’s settings for the Squeezebox only offered options up to 48K, not 96K, as it should have. I discovered this while looking for a temporary workaround for the underlying issue. No idea if it might indeed be a symptom of the main issue. But it certainly feels like it could be. In any case, this isn’t the swamp we set out to drain.*

  3. The queue view (as toggled by the little icon in the scrubber bar) fails to show any tracks in the queue if an album is playing from the Linux server. From the Mac version of the server this feature behaves as expected. I didn’t put any real effort into trying to isolate this. I just noticed it. Related or a separate issue? I have no idea.

  4. No audio when playing to a Squeezebox 3 endpoint. I never checked to see if the Mac version of the server behaved any differently. It’s the least of my problems, frankly, but who knows, it might be related.

When I played the Linux server to a Roon endpoint instead of the Squeezebox Touch, high res files played correctly.
The “limit sample rate” dialog appeared correct, but since it reflected a different end point, I doubt that means anything useful.

When the Mac server is in use, all the features - high res files, the sample rate dialog and the queue list appear to function as expected. I didn’t check the function of the SB3 with the Mac server in play.

Squeezebox has a function to check network throughput to the endpoint. (LMS-to-SB) I used that and there was enough bandwidth available for a 24/192 FLAC stream, but not a lot of headroom. Given that 24/192 works Mac server-to-Squeezebox (barely), Linux server - to - Roon endpoint, and LMS-to-Squeezebox, I’m disinclined to think that we’re seeing networking issues. (The Mac server is running on a laptop, so there are more WiFi hops when it’s in use. I would expect less throughput in that case. But I can probably lash up a wired connection to the same gigabit switch the Linux server and the data store are on, if need be for testing.)

*I’m from Florida and we now know that draining swamps is not usually a good idea. But I like that expression anyway.

As I’ve got issue 1 as well, I can inform you that imho it’s not related to point 2. In my case the dialog does show the ‘up to 96K’ as option, and indeed plays everything fine at 96K.

It’s when I switch to 192K I get the noise.

Hope this helps!

@Carl_Seibert ---- Thank you for the follow up and very thorough feedback :+1: This information is greatly appreciated. I have this issue slated to discuss with my team and would like to confirm just one more bit of information based on your posts.

  • You are working with two different squeezebox touches.

  • One runs firmware 7.80 w/ EDO 0.9

  • The second runs firmware 7.73 (EDO Plug-in?)

Can you provide some insight why the second touch hasn’t been bumped up to 7.8.0 as well? Many Thanks!


Hi @spockfish ---- Thank you for chiming in and my apologies for the trouble. To confirm you are having the same issue listed above.

  1. High res playback failed after a variable period of time when playing from the Linux RoonServer to the Squeeze endpoint. This is the central issue, as far as I’m concerned. It almost felt like it could be related to something that gets cleaned up by the overnight cron jobs. The “first” session of a given day would play longer before failing than subsequent attempts. After one failure to noise, an attempt to play a track would only last a minute or so. As far as I can tell, there were no events associated with when the stream failed.

Can you also confirm what version of the firmware you are running as well as what version of the EDO plug-in you are working with.


Hi @Eric,

No need for apologies. You guys are doing an awesome job!

I’m indeed the running the latest firmware, 7.8 and EDO 0.9.
The reason I did that was actually driven by this issue, as I wanted to see if the latest-greatest on Squeezebox side would help out.

Regards Harry

@spockfish ---- Thank you for the follow up and the kind words :slight_smile: Very pleased to hear you’ve been enjoying your experience with roon. I’d like to gather one more piece of information from you. Please see below. Thanks!

May I kindly ask you to please describe your current setup, in detail, as seen here. I want to get an understanding of the gear you’re working with and how everything is communicating.



  • RoonServer on Linux (157) on a 64-bit Linux (openSUSE)
    (i5-2450, 2 cores)
  • Music stored on a Synology NAS, mounted over SMB on the RoonServer
  • Logitech Squeezebox for playback: 7.8.0 and EDO plugin 0.9

All wired. No wifi involved.

It could very well be that my RoonServer is underpowered (I know you guys advice some pretty serious hardware), but then still I want to understand what @Carl_Seibert is describing, namely that it seems related to the Squeezebox endpoint, and not the server.

Actually, no. There was some issue prior to upgrading LMS to 7.8.0 that caused me to do that. Since it’s been working fine, I haven’t paid it any mind since.

As soon as I realized there was an issue, I mostly left that SB unplugged while I did all my testing with the other one.


As it turns out, I’m pretty sure the issue is server-side. My Squeezebox endpoint works totally fine with either LMS or Roon running on the Mac laptop.

Interesting that your data store is also on a Samba share… I wonder if that could be significant or if it’s just coincidence based on that being a logical way to run Roon. Maybe everybody does it that way…

Hi @Carl_Seibert - Thank you for the update and your continued feedback. Both are greatly appreciated.

We would be really surprised to hear if there were differences in our squeezebox support across the core platforms, as they share common code and should behave the same.

Can you confirm that your linux server is able to play to other network zones without issues? You can test this with any supported OSX, Windows, or Android device, or with a Roon Ready device if you have one.


Yes, the Linux core plays just fine with a Roon endpoint. (The Mac laptop. I think that was in the OP, actually :wink:

Indeed, there are lots of places to look. Mono, memory leak, IO maybe, something in configuration, maybe even permissions. And of course the possibility that there’s an old bug or something. Maybe the logs will shed light. Hopefully, something will ring a bell with somebody who is intimately familiar with the code and we’ll have a place to start looking.

I’m assuming there are lots of users out there with Linux servers and data on Samba shares and Squeezebox endpoints and high-res files who are having no problems. On the other hand, that’s a lot of criteria. With both Linux and Squeezebox support being fairly new, there may not be many such installations out there…

I’ll do another test today by mounting my NAS over NFS in stead of SMB. It’s a long shot, but we than can rule out possible issues with the SMB mount for good.

Ok. Did a test met with NFS instead of SMB. In short: it did not resolve the issue, but I’ve noticed a few things that might help in sorting this out:

While my library was scanning I already started playing 192K content. Couldn’t help my self :slight_smile: Resulted in noise from the start. CPU load of my server at that time around 50% (because of the running scan). When the system was ready with scanning and idle again I retried. This time I could play 192K content for a long time, but failed in the end (after a minute or 10).

Now the weird part: if you think about this than you could easily draw the conclusion that this is server load related. When the noise arrived i switched to DSD64 content, which is being resampled to 176K content. Now, this takes more load on my server than playing 192K content, but it’s now playing fine for about 20 minutes…

@spockfish ---- Thank you for your continued feedback and sharing your observations/findings with us. Thank you as well @Carl_Seibert. My apologies for the slow response.

The squeezebox protocol is “pull” based – if it’s not getting audio fast enough, then it really comes down to one of two factors: either the Squeezebox is not asking, or the “pipe” is too small. There should be clear indications in our logs if we were not getting data fast enough from the NAS, so Carl, we are going to circle back and double check those. Harry, are you able to dump me a set of logs from your Roon Server as well?

Our team has taken out a ticket for our developers to test these issues in house and I will be compiling all of your provided info and logs into one place for analysis.


@Eric sure! I’ll try to do this tonight.

Regards Harry

1 Like

@Eric - Let me know of you need more log files. I just grabbed the one that looked like it covered an appropriate time frame. RoonServer appears to make one per run, so I have a zillion to choose from.

As for the two factors you cite, bear in mind that the Squeezebox client works fine with RoonServer running on a Mac. That would appear to exclude client-side failings and, especially given that the Mac’s network situation is a bit more challenged, pretty much verify the network. IO on the machine itself (or on the machine with the data) seem to me still to be in play.

I’ll look and see if I have a snippet of the machine’s log for the time period of the RoonServer log I sent and pass that along if I’ve got it.


Oh, and one other thought: Does anybody know what the failure to noise is a symptom of? Network slowdowns appear to cause a pause, but not a failure to noise. Is this a sync issue, maybe?

1 Like

@spockfish ---- That would be very appreciated, thanks!


Hi @Carl_Seibert ---- Another set of logs would be great, thank you!


Hi @Eric, here’s a link to a log file

Some details: noise popped in at 20:26 blank.
I let it ran until 20:27 when I skipped to the next track.

Now the rather bizar thing: when it started playing the second track there was immediately noise, but through the noise (that’s the only way I can subscribe it) I heard music. So it sounded extremely distorted, but it was recognisable.

I’ll hope you guys can make something out of this. If you need anything else than just drop a hint.


1 Like

Here you go. This is the messages log and the RAAT server log for the time covered by the RoonServer log. (Sorry for the avahi pollution. After I saw that I upgraded avahi to the newest version in my distro’s repository and it reduced the nonsense somewhat. But the actual fix is in the first version that’s too new for Fedora 22, according to the interwebs. Arrgh.)

1 Like