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

24/96 files fail after a period of time on my Squeezebox Touch. Sometimes high res files will play for three or four songs, once even over a half hour, then fail to noise. Once playback has failed, attempts to play another high res file will fail in less than a couple minutes, usually in seconds. This with RoonServer (v1.2, build 157) running on my Fedora 22 machine. Roon was installed by the easy install script. Data is on a Samba share on a different machine.

When I change Cores and attach the Touch to a RoonServer running on my Mac laptop (also v1.2, build 157) 24/96 files behave as expected. 192 KHz material exhibits some pauses, but thatā€™s probably down to network issues, given the more complicated network path to and from the laptop.

96K (and 192K) music plays properly from LMS (7.8.0) to the Touch.

The ā€œlimit sample rateā€ dialog in Roon controller does not show an option above 48 KHz for the Touch when connected to the Linux server and properly shows 96 KHz as an option when connected to the Macā€™s server.

The Touch runs firmware 7.8.0 and Enhanced Digital Output 0.9. I stripped the firmware from the Touch, reinstalled it, and uninstalled and reinstalled EDO. Behavior was the same, both before and after each, and with and without EDO. Another Touch (FW 7.7.3) behaves the same way. Research on the Squeexebox Forums indicates that that there is no way of downgrading hi-res performance of the Touch, sort of rewriting its software.

The fact that music would play for a while and then fail made it very vexing to try to pin down where the issue was. Or, for that matter, what the issue was. I thought at first that it only manifested when EDO was set to ā€œdigital onlyā€. It turned out not to be dependent on EDO. That said, as I write this, the Mac instance of RoonServer -> Touch has been playing 24/96 material for about four hours. The only variable changed was the server, so Iā€™m pretty sure Iā€™ve isolated the problem.

And no, running Roon on my laptop is not a sustainable solution.

Ideas, anybody?

Iā€™ll attach a log file from the server on the Linux machine.Hmm. No I wonā€™t. Text files canā€™t be uploaded. Iā€™ll put it in Dropbox, here: https://www.dropbox.com/s/uvzxwxwu0vas82a/RoonServer_log.02.txt?dl=0

Another symptom: I just noticed that the Queue populates when you click play album as expected on the Mac server, but not on the Linux one.

1 Like

Now this is interesting, as Iā€™ve got exactly the same situation! I only gave up on it, and never thought about doing the experiment with RoonServer running on a different platform :wink:

I can add to this description that in my case it seems to only happen when playing 24/192 material.

Would love to see this resolved.

Letā€™s ping @support to see if they can replicateā€¦

Yeah, I chased my tail all over the place, figuring it just has to be on the client side. Oops.

Just leaving a tag for @support to pick up.

Oh, and one more tidbit:

I did try the Linux server to a Roon endpoint (the Roon software bridge on that same Mac laptop) and 24/192 material played fine to a USB headphone DAC/amp.

Hi @support, did you already looked into this?

Thanks!

Hi @Carl_Seibert ---- My apologies for the slow response and for the trouble here. I saw that you had dropped in a download link for logs :clap: and I went ahead and grabbed those to pass over to our developers for review.

Your observations are indeed interesting:

Test #1

24/96 files fail after a period of time on my Squeezebox Touch. Sometimes high res files will play for three or four songs, once even over a half hour, then fail to noise. Once playback has failed, attempts to play another high res file will fail in less than a couple minutes, usually in seconds. This with RoonServer (v1.2, build 157) running on my Fedora 22 machine.

Test #2

When I change Cores and attach the Touch to a RoonServer running on my Mac laptop (also v1.2, build 157) 24/96 files behave as expected. 192 KHz material exhibits some pauses, but thatā€™s probably down to network issues, given the more complicated network path to and from the laptop.

Test #3

I did try the Linux server to a Roon endpoint (the Roon software bridge on that same Mac laptop) and 24/192 material played fine to a USB headphone DAC/amp.

Can you identify any patterns, similarities, or difference youā€™re finding between these three different scenarios youā€™ve highlighted? I am trying to pin-point where, if any deviations could be between these three tests. Many thanks!

-Eric

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!

-Eric

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.

Thanks!
-Eric

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.

-Eric

Sure.

  • 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.

-Carl

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.

Thanks!
-Eric

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.