Radio is not selecting next song on Arc. Yesterday, 12 April around 15:21 UTC, I started playing a song on Arc on my iPhone (outside my home network). With Roon Radio enabled, I expected it to choose a matching next song automatically. But it simpy stopped playing. I tried three times with the same result. When I then selected the same song and said "Start radio", new songs were queued as expected.
Describe your network setup
Internet connection 250 Mbits down/250 Mbits up, TP-Link network devices with Omada network controller
Thanks for reaching out with your report. We’ve activated diagnostics for your account, but what is strange that there is no diagnostic data at all for the last month. Are you by any chance using ARC in offline mode or with another Roon account? Does the same behavior happen with the track when using the regular Roon app? What was the track/artist that was affected?
I have not used Arc an awful lot, but I have used it, so I’m not sure why there’s nothing there. I only have one Roon account and that’s the one I’ve been using, obviously. I’ve never used offline mode.
I’m not at home right now, so I can’t test whether the same problem occurs on the Roon app, but I don’t think it does. But on Arc I just reproduced it with the same song. When it starts playing, it says at the bottom of the play list “Roon Radio Starts after the music ends” but when the music ends, it ends for good and it says “Nothing playing Go find something to play”.
I just tried another song and the Radio found one to play next without an issue. So it’s not a universal problem but related to certain tracks. Which makes me wonder how Arc Radio is programmed. If - for whatever reason - Radio fails to find a next song - shouldn’t it take it’s job a bit more seriously and try again?
I don’t have this track as local content. But since you’re asking: I assumed that Roon Radio doesn’t analyze the actual audio file/ stream, only the metadata. Since the Metadata would obviously be the same, regardless of whether the track is local or on Tidal, I didn’t think this question made sense. Could you point out where I’m going wrong?
Hi @Papatistos,
Thanks for sharing the name of the track. We use that information to quickly locate errors in your logs so it’s very helpful to have.
Regarding reproducing this with local content it doesn’t need to be the same track that you test. It can be any local content that you happen to have. The reason we’re asking you to do this is because it helps us determine whether the issue is streaming service specific or a wider problem with the Roon server.
I know it is always convenient to ask for more information, but please consider that I am using Roon because I want to enjoy music, not to test a lot of different things. It is sad that I sometimes have to invest time into reporting issues that prevent enjoyment, but I do it because I believe that my reports can contribute to a better Roon experience.
I would like to suggest that you try to narrow down the sources of error based on the information I already provided:
the problem can be reproduced with that particular track, both over cellular and over wifi (in the Arc App but not in the Roon app)
the problem does not exist when the track is played via “Start Radio” (instead of “Play”)
We’ve noticed ARC is not retaining any logs for your account, which usually occurs when software on the phone prevents our log servers from properly resolving.
Are you using NextDNS? Does the Omada network controller you’ve mentioned in your setup have a corresponding remote access VPN on the phone? If you are using either or these or similar DNS-regulating software, please add the following domains to the whitelist:
Roon Radio failures are hard-coded to prompt a “nothing similar found” error rather than the UI popup you’ve indicated. Based on the error received, then, it’s actually the queueing of the radio tracks themselves that fail. This isn’t expected behavior when radio is toggled on, obviously, and even if the subsequent downloads to the queue had failed (from either Tidal’s API or your own server/storage at home), you should have seen an error concerning connectivity instead.
Server logs reveal that the radio request for the seed track you mentioned on April 12 successfully processed. We need to see granular logging from ARC to assess why the playback engine can’t get ahold of these tracks.
I have added them now. Is my understanding correct that this is necessary for troubleshooting, not for ordinary use, right?
Which request are you referring to? I made 3-4 requests in the form of just playing the track (expecting the Radio to pick subsequent tracks). This failed. My final try, immediately after these initial tries, was to select “Start Radio” on the same track and this worked. Is that the one you are seeing as successful in the logs?
Are you sure the problem is with the playback engine not getting hold of the track that Radio selected, rather than radio not selecting a track? Because from a user perspective, there is no playback failure (in the sense of a track in the (radio-)queue not playing). The failure is that no track is being queued. (It may well be as you suggest, but that would mean that, technically, it is not the Radio that queues the tracks but the playback engine, and that the playback engine only puts them into the queue when it has confirmed access to them.)
I have tried to reproduce the issue at around 10:15 UTC today, but unfortunately (?) it worked this time…
I have added them now. Is my understanding correct that this is necessary for troubleshooting, not for ordinary use, right?
You are correct — these domains are only required for troubleshooting purposes. They need to be whitelisted in order for us to receive diagnostic data from the device running ARC.
Regrettably, even after adding the domains, we are still not receiving any data. Would it be possible to temporarily disable NextDNS and let us know once that’s done?
Hi @Papatistos,
Good news — it looks like the logs are coming through now. I think the next step is to have our developers take a closer look to see if they can determine what’s going on. I’ll create a ticket to get that process started. As soon as we have more information, I’ll follow up with you here.
Logs have fully populated to our cloud diagnostic servers. Thank you for taking the time to help us gain access to those - it should greatly expedite this investigation.
Here’s what we see happening:
During the initial radio failures with “Crossing Muddy Waters” that prompted this report, ARC had lost connectivity to the server only seconds before the radio initiated. The POST request to gather he radio session from your RoonServer returns 404.
Somewhere in between. RoonServer has already selected up to 15 tracks to queue for Roon Radio long before this track completes. What’s failing here is the connection between ARC and RoonServer - ARC requests the session from RoonServer, can’t reach it, and nothing populates. ARC regains sight of the server within just a few minutes, so you’re not losing session authentication entirely and hitting a lockout (“Server is offline”) screen.
That doesn’t mean this is working as expected. If ARC has no server access, it’s expected that you’d receive a popup warning before failures begin to accrue.
The most useful test would be to attempt to reproduce this while standing next to your RoonServer on your home WiFi. You may have already tested this, since we see a mixture of WiFi and cellular connectivity in diagnostics.
Wow, thank you for the detailed explanation. (I’m also impressed that the logs are coming through even for events that occurred before whitelisted those domains.)
But I don’t quite follow how the problem can have been the connection between Arc and RoonServer, given that playing the track via “Start Radio” worked fine. This cannot be explained by coincidence (“connection happened to recover just when I switched strategy after failing three times”) because I was able to reproduce this multiple times.
Or can the “Start Radio” process somehow do without a server connection?
Start Radio automatically fetches the radio queue, while pressing play would only kick off radio at the end of the current queue, so they are a bit different mechanisms. Have you been able to try out @connor 's suggested test?
I understand that. But in both cases the radio will eventually be kicked off, so I don’t understand why it fails in one scenario but not in the other. What is the difference between “fetching the radio queue” and “kicking off radio”?
Yes, as mentioned earlier, I have been able to reproduce this both via wifi and cellular.
Today I had the same issue on Roon. I queued an Album with two tracks, made sure that Roon Radio is enabled so that the music doesn’t stop but Roon just stopped playing at the end of the Album. Unfortunately, the history does not provide the exact time, but it says “4 hours ago”, which would be 09:40 UTC. The last track (after which the Radio should have kicked in) is called “Aywah (Original Mix)”. Hope you can find it in the logs.
(BTW: I just noticed that it is not possible to copy the text from an item on the playlist, which is a bit annoying.)
Thanks for letting us know @Papatistos - we’ll be discussing your case with our Arc team before the end of the week and should have more information to share afterwards.
