Hi @vadim,
Glad to hear that. Please keep me posted on the progress.
Best
Jason
Hello @Jason_Kim ,
We have reopened this thread as per your reopen request. Can you please confirm if you are still seeing the same issue at the present time? According to the internal communication I see, it looks like some server-side changes were made, but please confirm if they helped on your end or not. Thanks!
Hi @noris,
Unfortunately, it’s still the same.
02/20 09:43:34 Debug: [easyhttp] [8311] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-02-20T09%3a43%3a10.3273000&c=tidal-us&languages=en,%3Een&tidal=max returned after 25809 ms, status code: 500
The client and the server are both 2.60 build 1629 FYI.
I forgot to mention this. I reinstalled the roon server to a different physical machine. It’s currently on a different box. But the issue is still the same. FWIW.
Hi @Jason_Kim,
The team is still investigating this report. The discover service itself was briefly down last week but is functional again. I assume you’re still seeing timeouts at this time.
Thank you for the update.
Yes. I’m still seeing the timeout issue.
Hi @Jason_Kim ,
There were a few additional serverside changes after your post and a new Roon release went out, are you still seeing the issue presently on the new build?
It’s very unfortunate but it’s the same. My server/client the both are 2.62 build 1641.
03/05 10:25:27 Debug: [easyhttp] [1487] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-03-05T10%3a25%3a08.0072807&c=tidal-us&languages=en,%3Een&tidal=max returned after 20494 ms, status code: 500
03/05 10:25:30 Debug: [easyhttp] [1496] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-03-05T10%3a25%3a08.0200999&c=tidal-us&languages=en,%3Een&tidal=max returned after 23765 ms, status code: 500
03/05 10:25:31 Debug: [easyhttp] [1505] GET to https://api.roonlabs.net/discover/1/mixes/profiles/6ac695f0-1dbd-47d1-8902-de49a5bfc72e/mixes?localTime=2026-03-05T10%3a25%3a08.0205028&c=tidal-us&languages=en,%3Een&tidal=max returned after 24818 ms, status code: 500
Hello @Jason_Kim
Thank you for the update. We have bumped this issue to the R&D team and will keep you posted with the progress.
Thank you vadim.
At this point, I’m curious to know what’s the expected result if this API doesn’t fail? I’m asking this because I think I’ve never seen it work so I’ve never seen the result on my front page.
Can you please share what information has been missing from my front page because of this? A sample screenshot?
Hi @vadim
Thank you for the screenshot.
That looks cool but I don’t think that’s a critical feature for me. But the current problem is it blocks loading my page for a long time. Every time I open the home tab. I have to wait a minute to see the rest of the page. It’s very frustrating.
If we can not fix this easily, how about adding a config option to turn off the tidal daily mix? Probably to this panel?
I want to turn that off until we can fix this issue.
Hi @Jason_Kim,
We welcome this suggestion in the feature suggestions category if you’re willing to share it there:
Here’s the status of this discovery API issue:
The team is continuing to monitor this particular service closely. For your particular network pathway, it’s intermittent, and there’s room for improvement. The team has plans to rework this long-term but we don’t currently have a timeline for when that work will be released. We will certainly keep you in the loop here. Thank you again for your patience.
As I said, I haven’t even seen it work. It’s not intermittent. It fails always.
Hi @Jason_Kim,
Thank you for your continued patience while we investigate this.
I want to let you know that this issue has been officially documented and is currently being reviewed by our development and R&D teams. We’ve shared all the technical data and logs you provided, which have been instrumental in helping them isolate the behavior.
At this stage, we are waiting for a detailed assessment from the engineering side. Because this involves backend services, we cannot provide a specific ETA for a fix just yet, but please be assured that the internal ticket is active and being tracked.
Thanks for your understanding.
I found after todays server update to 2.64 (build 1646), this finally works without timeouts.
I can not find anything related to this in the release note though. Can you please confirm this was due to your fixes on this? Maybe it wasn’t because of the update but some of your backend server side fixed this. Maybe the timing was just a coincident.
I’m gonna monitor a few days if it’s regressed.
Hi @Jason_Kim,
There were no specific updates related to your issue released in the last update, but I’m glad to hear things have stabilized for you.
We’ll leave the thread open a bit longer to ensure you have more time to test. Thanks! 