I’m new to ROON even though I’ve had a subscription for most of a year. (My internet wasn’t solid). I’ve now got hardware working at several endpoints using RPI’s, and my library is fine. All of this works great! However, when I try to use the internet radio feature, it drops after a few seconds to a few minutes.
I’m using an i7 pc with 16gb memory for my ROON core and solid state drives. My internet is dedicated business-class hi-speed. A Speedtest on the PC show 80-100 mb download speeds. I run my ROON system on a hardwired ethernet connection and all my endpoints are hardwired to my LAN.
I have to assume that the problem is within ROON since an hardwired hardware internet radio receiver. My plan, however, is to run everything through ROON, and preferably before I have to renew my ROON license. Any help would be appreciated. Thanks.
I’ve just experimented with a couple of local stations. I don’t know how to tell if the broadcasts are mp3 or whatever. The 2 local URLs I have tried are:
As a whole, I have not found that iheart radio addresses work in Roon. Use TuneIn Radio address. Open TuneIn and enter the call signs. That is how I got WSYR.
Hi Daniel,
Thanks for your help. I was able to tune the stations in, but they still drop off by often losing connection. I’m not sure where the problem is but it may not be in ROON.
I am not an audiophile, but I really do enjoy quality music reproduction. I understand and love the concept of ROON and now have 6 endpoints. My wife likes radio, including music, news and talk in the background, wherever she is, and we live in a rural area where we can’t receive over-the-air broadcast effectively. That makes internet radio perfect and important for us.
My next step is to check out my hardware. I have a dedicated high-speed fiber line running to my business which my residence is connected to using a high-speed wireless bridge. My tech guy suspects one of the routers. We’ll be checking it out.
If I find out anything I think is useful to you and others using ROON, I’ll pass it along.
Hi Daniel,
I’m becoming convinced that a lot of drops problems with individual radio streams are due to problems of the radio station itself. I’m sure there are standards that must be adhered to in order to deliver a stream with minimal drops. Is that the case? If so, what are the pitfalls that can be avoided?
Any tips or words of wisdom would be appreciated as I intend on talking to the radio station staff about the problem. Having recommendations for improvements is always a good way to open a productive dialog.
Thanks, Paul
Hello Again
As a former IT guy, I get suspicious when things repeatedly go awry in the same way. Perhaps here’s a clue that may be helpful with the internet radio drops issue I have been having.
I am using Raspberry PIs with Hifiberry boards (both Digi+ and DAC+) to control endpoints. When I tune in a station that drops or loses connection I get an error message suggesting a bad address. When I retry to connect I get the same message. Then when I go back to the main menu and try to access my music library, usually by artist or genre, the endpoint stays locked up.
In order to resume any music playback, I have to physically break the network connection by unplugging the ethernet cord of the RPI (or I can reboot the RPI). This seems to be a solid failure regardless whether using an RPI with the Digi+ or DAC+ board. Accordingly, I have to assume there is a problem with the ROON core software.
One possibility is that when the buffered incoming stream actually runs out (perhaps as opposed to running low), the ROON core erroneously loses its network connection, either with the radio station or with the local endpoint.
Another possibility is that, assuming there is an output streaming buffer, it gets filled up when the endpoint connection is broken. Then it just sits there waiting endlessly.
The clue worth noting is that the non-functioning endpoint still remains on the zone selection list. Accordingly, it seems that the ROON core thinks the endpoint is still there and assumes that everything is normal.
I don’t know if this is going to be helpful, but I hope is will be.
-Paul
p.s. Is it possible to have too many endpoints running on the Room core? I have 6 at present with a couple more to add. My ROON core is running on a 64-bit Windows 7 Home system with 16gb RAM and a couple 250gb SSD’s for storage. At present I only use it for ROON.
Hi Paul. Like library size and DSP usage, number of endpoints figures into what CPU to use for the Roon core. I think, that Roon dedicates a core to handle each endpoint.
But, to your issue. Does this drop off only happen with the Internet Radio Feeds? If you just play nothing but local content do the dropouts happen with the Pis?
Also, does the drop out happen if you shut off all endpoints and run with just 1 Pi endpoint?
Hi Daniel,
It seems that it is only the internet radio feeds that are causing drop offs. While I haven’t decommissioned my local content during active operation, local content also becomes inaccessible to the endpoint after an interrupted internet radio feed.
What is interesting is that when I run ROON on the PC with the ROON core using a direct link to a music system (connected using the PC’s sound card), even that hard-linked endpoint experiences a drop off and becomes unresponsive.
This suggests that the bug likely exists entirely within the ROON core software. After the endpoint buffer in the ROON core has been emptied, the ROON core seemingly has to perform a controlled pause to the endpoint. Normal operation should be resumed once the buffer has been refilled. But it isn’t being resumed and the pause becomes endless.
From the perspective of the ROON control, it simply isn’t aware that there is a bug in the ROON core. As a user, I can try to change over to my library and even select a genre, artist, etc., but I can’t play it because the ROON core doesn’t think there is buffered data to send to the endpoint. Accordingly, ROON control seems fine (I use android on my phone and iOS on an iPad).
I don’t think there is a problem with endpoint software on the RPI as well, because a forced physical disconnect brings everything back into operation. At first I just rebooted the RPI. As expected, this immediately resolved the problem. Then under the same conditions, I simply disconnected and then reconnected the ethernet cable without rebooting the RPI. This, too, resolved the problem.
My conclusions:
ROON control work right as long as the ROON core is working right.
ROON endpoints, at least when the endpoints are RPI’s, also work right as long as the ROON core is working right. If I had a non-RPI endpoint, I would want to test it as well. I have to believe they would work correctly as well. And because a DIRECT connection also failed under the same conditions, it also helps to verify this conclusion…
ROON core has a bug. The bug obviously occurs after an internet radio drop. Once the ROON core’s endpoint buffer empties, the ROON core seemingly has to initiate a controlled pause to the endpoint. At this point, if the buffer actually remains empty, more trouble shooting is going to be needed. However, if the buffer does refills but does not resume sending data to the endpoint, then I think the bug could be as simply as not triggering the resumption of normal operation.
I’m assuming and guessing a lot as to how ROON works, but maybe some of what I shared will be helpful.
-Paul
p.s. There certainly could still be a problem with the implementation of streaming standards by radio stations. But I think it is important that ROON do its best to overcome as many of the obstacles caused by sloppy implementations of standards as possible. I think that most failures are going to be blamed on the immediate software being used. That would be a bad deal for ROON.