Unfortunately the problem has started occurring again today.
After a full evening yesterday of Roon Radio working without any display problem, the problems have started to occur again today. Started playing Roon Radio in the early afternoon and the first few track selections were ok. However, just noticed that the last few tracks have displayed no background photos, album or artist details (display page completely blank). I have just stopped and restarted the Windows 10 Roon app and details have started appearing again, but I suspect not for long.
Update :The first few tracks were fine, but the last couple of tracks again display completely blank screens - no details whatsoever - 14:55, and now displaying details intermittently again.
Update 2: The âerror loading pageâ message has started appearing again (Sat 15th Feb, around 10:25).
Really strange that for the best part of a day the errors went away completely - strangely a period that almost aligned with the duration of the âChromecastâ problem that I and others experienced. The return of my problems occurred at around the same time that a resolution of the Chromecast was put in place - although Iâm sure that must just be a coincidence.
Looking through your Roon logs, I am seeing the following traces when trying to access TIDAL content:
02/14 14:52:37 Debug: [easyhttp] GET to https://metadata.roonlabs.net/1/performers/122:0:MN0000131295/refs?c=tidal-gb returned after 1265 ms, status code: 200
02/14 14:52:39 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
02/14 14:52:39 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
02/14 14:52:40 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
02/14 14:52:40 Trace: [Muso] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 1:18/4:05] Skyline Drive - Shahin & Sepehr
02/14 14:52:40 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
02/14 14:52:41 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
At your timestamp:
02/15 20:47:15 Debug: [easyhttp] GET to https://metadata.roonlabs.net/1/albums/166:0:1410980/reviews?c=tidal-gb returned after 1539 ms, status code: 200
02/15 20:47:16 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
02/15 20:47:17 Warn: [easyhttp] web exception without response: Name or service not known Name or service not known
And Iâm even seeing Airplay lost packets when playing back content:
02/14 12:30:30 Trace: [Muso] [HighQuality, 16/44 TIDAL FLAC => 16/44] [100% buf] [PLAYING @ 0:23/2:30] I Will Wait for You - Barbara Dickson
02/14 12:30:31 Trace: [airplay/client] server lost 1 packets starting at seq 43142
02/14 12:30:31 Trace: [airplay/client] resent packet to 192.168.0.12:1277 with seq 43142
02/14 12:30:31 Trace: [airplay/client] server lost 1 packets starting at seq 43143
02/14 12:30:31 Trace: [airplay/client] resent packet to 192.168.0.12:1277 with seq 43143
02/14 12:30:31 Trace: [airplay/client] server lost 1 packets starting at seq 43144
02/14 12:30:31 Trace: [airplay/client] resent packet to 192.168.0.12:1277 with seq 43144
02/14 12:30:31 Trace: [airplay/client] server lost 1 packets starting at seq 43146
02/14 12:30:31 Trace: [airplay/client] resent packet to 192.168.0.12:1277 with seq 43146
All these traces point back to network instability somewhere along the line, my first suggestion here would be to replace the ISP-provided router with a consumer grade one, I strongly believe that a new router would greatly help with the issues you are experiencing.
Thanks for this, although it is a bit unfortunate that you have looked at the logs for this particular period.
ON these occasions I happened to be streaming Tidal via my Naim Muso Qb over wi-fi. In fact, this may have been the only occasion that I have ever used my Muso to play Tidal material. Normally my Muso is used only for Internet radio only (BBC or Radio Paradise), and performs well over wi-fi for this function, and my main systems (which also experience the problem) are hard wired (ethernet) and not over wifi.
On this particular occasion 14/15 Feb, I was simply checking to see if I could replicate my problem when using the Muso rather than my main systems.
My use of Tidal via Roon is normally always with one of my main systems which are hardwired:
Main system: Linn Klimax DS/1 (2nd gen) connected by ethernet to a Cisco 2960 switch which in turn is connected to my Sky Q router.
2nd System: Mytek Brooklyn+ DAC with Sonore microRendu connected by ethernet to a different Cisco 2690 switch which in turn is connected to my Sky Q router.
It would be a more relevant test if you looked at my Roon logs for a period when I have been using my Linn Klimax based system.
I will be using my Linn KLimax with Roon Radio for most of today, and so logs from 19th Feb would be more relevant when checking my problem.
A quick question for you. I have just had a look at my logs, and I cannot see any logs for today (19th Feb) although logs are there for 18th Feb. When are logs written to the Data folders? At the end of the day? Whenever the NUC/Roon Rock are switched off?
I have just checked the logs for 14th and can see the lost packets you mentioned when streaming over Airplay to my Muso - not a big surprise.
However, I can not see any similar messages when I switched to using my hard wired Linn Klimax. I do however see a few odd messages such as:
âDestroyed domainâ
[zone Main Room - Klimax DS] queue got oversized. trimming 6 items from start
[zone Main Room - Klimax DS] Remove(6 items, for_replace=False)
[library] finished with 49 dirty tracks 5 dirty albums 1 dirty performers 22 dirty works 22 dirty performances
â[library/albumdetails] found 1 streaming service alternatesâ
Warn: [scd] [Linn Klimax DS] time discontinuity. Expected 0, Got 1
02/14 17:51:20 Debug: [easyhttp] POST to https://swim.roonlabs.net/1/session/3d09a39600624b3aa4f7ae4d78919d66/end returned after 2889 ms, status code: 200
02/14 17:51:20 Debug: [smc] [zoneplayer:3] Waiting for ordinal 75 (> 74)
02/14 17:51:20 Info: [ERROR_GETTING_TAG] [zoneplayer] Open result (Queueing): Result[Status=Success]
02/14 17:51:20 Info: [ERROR_GETTING_TAG] [zoneplayer] Open result (Queueing): Result[Status=Success]
02/14 17:51:24 Trace: [Main Room - Klimax DS] [Lossless, 16/44 TIDAL FLAC => 16/44] [22% buf] [PLAYING @ 0:05/3:20] Paradise - Govi
02/14 17:51:26 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:26 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:26 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:26 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
02/14 17:51:27 Debug: [prebuffer] sleeping in read â this isnât good
Logs are written in real-time to the Data/RoonServer/Logs folder. The reason why you might be seeing different times is because ROCK uses UTC in the logging and depending on which time-zone youâre in, it might be different than the actual time.
This message indicates that the audio stream didnât arrive quickly enough from the source to the audio destination. It can be caused by a variety of factors - insufficient network throughput, hard drive speed or the endpoint itself not processing the data quick enough.
Since Iâm seeing problematic behavior across all your zones and networking errors when trying to reach TIDAL servers, I believe this is very likely the network here, and as such I would suggest replacing the ISP router with a standard consumer-grade one instead.
I use Cisco 2960 Gigabit switches and cat6 ethernet cabling throughout my network.
My NUC8i5BEH on which Roon Rock resides uses an M.2 SSD hard drive.
The end points I normally use are a Windows 10 PC with core i7 CPU, an SSD hard drive & 16 Gb RAM, or an iPad Air.
I donât have any buffering problems of any sort with audio of any resolution up to 24bit 192 kHz streamed from my local NAS nor from Tidal Masters on any of my devices (via Linn Kazoo or Roon), and I have no problems streaming 4k video from Amazon Prime. I also have no problems streaming audio and video content from my SkyQ PVR to my remote SkyQ boxes elsewhere in my house over Wifi via the SkyQ router/hub. So, I would suggest that my local network is functioning pretty well.
I might add that I also get completely consistent âbit perfectâ MQA Master audio streams to my second system which uses a Sonore microRendu and Mytek Brooklyn+ DAC, as witnessed by the unwavering infamous blue light on my DAC.
My only problem appears to be intermittent issues with metadata for Tidal tracks selected by Roon Radio - no problems whatsoever with hi-res music streaming via Roon Radio - just the track metadata which I wouldnât have thought would constitute a high bandwidth requirement. It just seems intuitively a little unlikely that this is a problem with my router. Now even if I were to install my own router (and I suspect that this will not be allowed by my ISP - Sky), I would lose the Sky multi room functionality which really would be unacceptableâŚ
I understand that other applications are working as expected, but according to your Core logs, Iâm seeing issues with several of your endpoints and buffering issues.
It doesnât have a high bandwidth requirements, but from the diagnostics it appears that these metadata requests are not going through at all. This could point to a problematic DNS server along the line, but since changing the DNS server is not possible the next suggestion was to use a standard non-ISP router.
I am not too familiar with Skyâs multi-room capabilities, but would it instead be possible to add an additional router that handles just Roon traffic (ROCK + iPad)?
Just for information, this weeks update of Roon appears to have resolved this issue for me, or at least I havenât encountered the issue in the last couple of days since the update.
It also appears to have resolved another more irritating longish term issue for me. Roon Radio selections were frequently displayed with missing key info (such as album/artist info, artwork and background artwork). Again, this has not happened since I applied the latest update.
Glad to hear that the system is more stable after our latest update! If you encounter any further issues, just let us know and we can take another look, thanks!