Drop-outs (1-2 sec) issue due to a bad implemented license validation?

@benjamin: someone moved this topic out of the chain… Who made this (bad!)?

Anyhow the problem remains. The 1-2 sec. drop-outs are mostly caused by your cloud implementation.
NB: I recognized often DNS problems by my internet provider. Normally this does not cause issues but when Roon do not buffer IPs of cloud servers then a pending license validation could cause such issues…

Below as reference the original post:

@benjamin: a better idea would be if you guys review e.g. the license validation cloud connectivity and how a delay in such activities is managed by the Roon core… do you guys assure the streaming is not “interrupted” even if the license validation is “pending” …

BTW: The drop-outs issue happens also on my side (and this is the reason why I look to replace Roon completely). FYI: Tidal native streaming does not cause drop-outs.

I am a computer scientist, so “Microsoft-like” reboot tips are not really helpful (I made sure the network runs perfectly)

Hi,

your post reads like it has been clipped from somewhere else so are you asking a support question about the drop-outs you are experiencing or a general question about how Roon licensing checks are done?
Either way, as a computer scientist you will understand the requirement to provide full system details with your query, to enable help to be provided.
You would not be the first person to claim that their network ‘runs perfectly’ whilst experiencing possibly network related issues. What tests have you done on the network to assess the fitness of it?

@Antony_B: save your time and let support take care of those topics. It requires deep understanding of technical issues… Thanks

Hey @DanHP432,

Thanks for your patience! If possible, could you please fill out the necessary system info below:

Roon Core Machine

Include your operating system and machine info (Model, CPU, RAM)

Networking Gear & Setup Details

Your network gear (model of routers/switches) and if on WiFi/Ethernet

Connected Audio Devices

Specify what devices you’re using and their connection types, like USB/HDMI/Chromecast, etc.

Number of Tracks in Library

Tell us how large your music library is, eg. “30,000 tracks”

Description of Issue

Tell us about the problem you’re having in as much detail as possible. Screenshots are always appreciated!

With that, could you also please share a timestamp the next time this issue pops up? Sharing the name of the track would be helpful as well. Thanks!

@benjamin, first of all, thanks for the reply.

Second, as I already mentioned the equipment on my intranet works correctly. No packets loss (tested with ping, tracert, winMTR Loss%=0 on all target IPs within the intranet), no unexpected connections (tested with Wireshark), intranet latency <1ms on LAN.

Last but not least, here the data (from my point of view this will not help on this issue but anyhow)

Roon Core Machine

ROCK Version 1.0 (build 254) (NUC i7, 16 GB, SSDs -both the system and music storage). HD transfer speed (to and from …/ InternalStorage/… ) > 100MB (constant value without any speed drops).

Networking Gear & Setup Details

Synology Load Balancer/ Failover Router → FritzBox1 and FritzBox2 → IP1 1Gb and IP2 100Mbit

All parts of the Roon equipment are LAN - connected

Connected Audio Devices

The last one which is still connected with Roon is Mytek Brooklyn Bridge (LAN interface)

Number of Tracks in Library

This is not relevant. The issue is a Tidal streaming problem

Description of Issue

Drop-outs (1-2 sec). NB: There is no specific songs, timeframes or so… the drop-outs are completely randomized.

Hints: I tested the DNS response of IP1 and there are permanently packet losses (about 40%). Some reply’s take more than 5 seconds. NB: I can not influence this but the DNS packet losses do not cause issues with any streaming of 4k videos or music streaming services (Amazon Music, Internet Radio, Tidal using the Tidal native apps etc.).

So, one idea could be that you guys implemented the license validation procedures a wrong way (pings “home” and/or buffering of DNS addresses not sufficiently implemented …considering the 40% IP1-DNS-packets loss, I measured).

My solution (works without any drops so far): I changed the primary DNS to IP2 (packets loss 0%) but this is not the right way to stay at as I changed the failover process doing so (don’t know if the synology guys implemented all failover parameters correctly…)

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.