Music interruptions with ROCK, HQPlayer, and DietPi Endpoint after 2.71 update (ref#8EUXNP)

Support
1

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Hi Support,
Since the update to 2.71, the music has been playing with interruptions. I use ROCK as a separate instance, HQPlayer Embedded v. 6.0.2 on a dedicated computer, and the NAA Endpoint running the latest version of DietPi on my T+A SDV 3100 HV. Now, when I play music through ROON, the music is interrupted at regular intervals. The system goes silent for about 2–3 seconds and then resumes playback. The interval varies depending on the target format. DSD512 pauses after about 80 seconds; DS256 takes longer; PCM takes even longer. But they all pause and they all resume. If I access the SDV via ROON Ready, it works fine.
Guido

Tell us about your home network

· Speakers: Bowers & Wilkins 802D4
Amplifiers: T+A SDV 3100 HV, A 3000HV with PS 3000 HV
Source devices: T+A SDV 3100 HV
ROON-Rock on Proxmox
HQPlayer Embedded on an AudioPC
HQPlayer NAA Endpoint: DietPi on a NanoPi NEO4 in the SDV
Correction system: Convolution in HQPlayer with FIR filters from Acourate
Network: EtherRegen with a 10 MHz clock connected to the Farad Super3. fis Audio network cables, fiber-optic isolation to the FritzBox Internet Router

2

Hello @Guido_Specht

Thanks for laying out the full chain, that helps.

One thing to flag upfront: ROCK running virtualized under Proxmox is not a supported installation. ROCK is only supported on the specific Intel NUC models listed in our documentation, installed on bare metal. That does not automatically make it the cause here, but it does mean we cannot rule out the virtualization layer, and it limits how far we can take the diagnosis. If you have the option, running Roon Server on a standard Linux installation instead of ROCK would put us on firmer ground, and it is a supported configuration.

On the interruptions themselves, two things would let us match this against your logs.

First, please tell us whether the dropouts happen in the middle of a track, or at the point where one track ends and the next begins. Your description reads as mid-track, but we want to be certain before we start looking.

Second, please send us an exact timestamp for one occurrence: the date, the time, and your timezone, along with the album and track that was playing and whether it was a local file or a streaming service. That lets us find the precise moment in the logs instead of searching blind.

One observation worth sharing: the way the interval scales with format, with DSD512 dropping out soonest, then DSD256, then PCM lasting longest, is what you would expect if something is draining a fixed amount of buffered data at different rates. That is a useful clue, and it is another reason the exact timestamp matters.

It also helps that playback is clean when you go straight to the SDV 3100 HV over Roon Ready. That narrows things to the path through HQPlayer rather than the endpoint itself or your network to the DAC.

3

Hi Vadim, the dropouts occur randomly, after 5 minutes or after 20 seconds of a track.
Yello, La Habanera after ca. 5 min. at 18:39:30 CEST, Source: Local file on openmediavault, access via SMB
Fred again.. Kyle (i found your) after 20 sec. at ca. 18:50 CEST, Source: Streaming from Qobuz.

When going to the SDV via RAAT everything seems to work fine.

guido

4

Hello @Guido_Specht

Your timestamps were enough to find both events, and the answer is not what either of us expected. These are not dropouts.

In both cases Roon received a play/pause command and paused because it was told to.

La Habanera: at 5 minutes 5 seconds into the track, a pause command arrived, Roon paused, and passed the instruction to HQPlayer, which confirmed it.

Kyle (i found you): at 24 seconds in, the same thing. At that moment Roon’s buffer was completely full, so nothing was running short of data.

This is not isolated either. Over the last ten days your server logged 110 play/pause commands on the HQPlayer zone, against 2 on the SDV zone. So whatever is sending them is aimed at the HQPlayer path.

The short gap you hear is explained too. Five seconds after a pause, Roon releases the audio device, which is normal behavior. That is why playback does not resume instantly.

So the question becomes what is sending those commands. Please tell us:

First, is there any chance you paused these two yourself? Both stopped at exactly the point you described, so we want to eliminate that before chasing anything else.

Second, do you have any home automation touching Roon, for example Control4, Crestron, Home Assistant, or anything using Roon’s API?

Third, is there anything with a play or pause button that could reach Roon? A Bluetooth remote, headphones, a keyboard media key on any machine with a Roon remote open, or a phone in a pocket. Bluetooth devices connecting or disconnecting will send a play/pause toggle on their own.

Fourth, do you ever have HQPlayer’s own web interface open while Roon is playing?

One thing we would drop for now: we pressed you earlier about ROCK running under Proxmox. That is still not a supported installation.

A useful test in the meantime: next time it happens, look at the Roon app immediately. If the zone shows as paused rather than as an error or a lost connection, that confirms this from your side too.

5

Hello @Vadim,

So many interruptions? That sounds like a lot at first, although I didn’t notice them until after the update when I was listening.

There has been a new Roon update in the meantime, and I haven’t noticed any pauses since then. But the two weeks before that were an intense period of evaluating HQPlayer without a license, involving many changes to the settings and the open web interface.

I’ll be away from home for a few days and will check in again afterward. Guido