Intermittent playback issue during "Sweet Talkin' Woman" by ELO with all new network components (ref#5A7H27)

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

· This is in regards to ref# 112KH0. The problem still exists, and please note: 1) I have replaced my LAN's router; 2) I have replaced all of my switches with one, single 16 port model, connected directly to the router; 3) I have replaced every single Ethernet cable used by any Roon component; and 4) the problem just occurred when I was listening to an ungrouped zone.

The error occurred today, during the first minute of ELO's "Sweet Talkin' Woman."

Tell us about your home network

· As above. Best-rated TP-Link router and a TrendNet 16 port gigabit switch. Quality cables. >= 300 megabit downstream Internet via cable modem.

2

Hello @Dean_Clough,

First, I want to acknowledge the massive amount of effort and expense you have put into resolving this by completely replacing your router, switch, and all of your Ethernet cables. I can only imagine how incredibly frustrating it must be to have the music stop again after doing all of that.

I also want to apologize for some of the mixed messaging in your previous thread. I want to clear the air and gently pivot our focus back to what Benjamin noted earlier, because your latest logs for “Sweet Talkin’ Woman” confirm the exact same behavior.

To be completely candid: these are not network dropouts. Your new network is actually performing flawlessly, and the track buffered perfectly. We can see exactly why the music stopped: at exactly 49 seconds into the track, the Roon Server received an explicit, intentional PlayPause command over the network. It paused the stream, waited exactly 5 seconds, and then suspended the audio device to save resources. A few seconds later, it received an Unpause command and resumed playing.

I completely believe you when you say you are not intentionally pressing pause before the drop happens. However, because Roon is a centralized system, any device running the Roon Remote app (or a third-party integration) can control the server. What you are experiencing is a “ghost” command—a device somewhere in your home is inadvertently sending a pause signal to the Core behind your back.

Since your network is 100% in the clear, we need to play detective with your control devices. Could you take a look around your environment and see if any of the following culprits might be active?

  • Mobile Lock Screens or Pockets: Phones or tablets running Roon Remote in the background can sometimes have their lock-screen media widgets accidentally triggered by a fabric brush or a phantom touch.
  • Smartwatches: Devices like an Apple Watch or Garmin frequently take over active media controls. If the watch face rubs against your sleeve or wrist, it can instantly send a global pause command.
  • Keyboards with Media Keys: If you leave the Roon app open in the background on a Mac or PC, a highly sensitive, sticky, or accidentally bumped “Play/Pause” key will pause the music.
  • Bluetooth Headsets: Headphones connected to a computer running Roon often have “auto-pause” features (triggering when you shift them) or touch controls that can misfire.
  • Home Automation: Do you have any systems like Home Assistant, Control4, or physical volume dials integrated with Roon that might be sending a stray command?

To test this, the best approach is to completely close out the Roon Remote app on all your phones, tablets, and computers, except for the one device you are actively using to start the music.

4

Oh my. I ABSOLUTELY UNDERSTAND I PRESSED PAUSE!!! I pressed pause INTENTIONALLY so I could take a screenshot so I could document when (within a few seconds) the problem occurred. This is the second time someone at Roon has said the sound dropped because I pressed pause, so I will ask again: Do I seem that dumb?

The issue remains: I am listening to an ungrouped zone, over a completely new LAN, with no WiFi involved with any Roon component. And intermittently, the sound drops out. The issue has occurred on a wide variety of tracks, both local and streamed via TIDAL. The endpoint to which I am playing is also new - it is a new HiFiBerry Digi + on a RPi running RoPieee. Please note I have had Roon for many years, and have never experienced this issue y zone, ever.

Except until the last major release, which I mentioned in my original trouble ticket.

5

Hello @Dean_Clough,

First and foremost: I am incredibly sorry. You absolutely do not seem dumb, and your logic makes perfect sense. I sincerely apologize for our team completely misinterpreting the sequence of events and making you repeat yourself.

Let’s clear the slate. We completely understand now: the audio drops out first, and then you intentionally hit pause to mark the timestamp for us.

Here is why this has been so confusing on our end, and why we need to change our troubleshooting approach.

When we look at the Roon Server diagnostic logs, we are only seeing the system from the Core’s perspective.

From the Core’s point of view during “Sweet Talkin’ Woman,” everything was running at 100%. The network buffer was full, there were no internal errors, and the RAAT protocol reported that it was successfully handing the audio data off to your network without any interruptions. The very first “event” the Core registered was your intentional pause command.

This means that the Roon Server is completely blind to the physical dropout you are hearing. If Roon Server thinks it is sending data perfectly, but the music stops coming out of your speakers, the break in the chain is happening downstream from the Core—most likely right at the endpoint hardware itself.

Since your network is brand new and stable, the prime suspect is the new HiFiBerry Digi+ and how it’s communicating via RoPieee. Sometimes, an underlying Linux audio driver (ALSA) can momentarily drop its S/PDIF signal to the DAC, which causes silence without sending an error back to the Roon Core.

To figure out exactly what is causing this physical dropout, we need to look at logs from the Raspberry Pi itself.

Here is what we recommend for the next step:

  1. Generate Feedback: The next time a drop occurs, please immediately log into your RoPieee web interface, navigate to the Advanced tab, and click the Send Feedback button. This will generate a unique identifier for your device’s logs.
  2. Post in the RoPieee Category: Once you have that identifier, please head over to our dedicated #audio-gear-talk:ropieee category on this forum and create a quick post.
  3. Tag the Developer: In your post, please tag @spockfish (Harry, the developer of RoPieee) and provide him with that unique feedback identifier, along with a brief description of the dropouts.

Harry is incredibly helpful and will be able to pull the exact kernel logs from your Raspberry Pi to see exactly why the audio hardware is dropping the signal locally.

Again, I am very sorry for the earlier frustration. We are entirely on the same page now, and getting those RoPieee logs to Harry is the best path to tracking down this hardware interaction!

6

Thank you.

7

@Dean_Clough ,

You are welcome, if you have any problems with reaching to the developer of Ropiee please let us know .

Thanks.

8

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