Endpoint stops playing, then recovers after a couple of minutes

Core: Roon 1.7 build 571 stable 64bit, Windows 10 Pro 64 bit Version 1903, Lenovo Thinkpad X1 Tablet (name: RNX1TAB), i5-8250U, 8GB RAM, 512GB SSD, System Output

File server: Windows 10 64 bit, Dell, i3-6100, 4GB RAM, 128GB HD (OS), 2TB HD (Data)

Endpoint: Roon 1.7 build 571 stable 64bit, Windows 10 Pro 64 bit Version 1903, Lenovo M720 (name: M720HT), i3-8100T, 8GB RAM, 256GB SSD, Topping D10 USB (toslink conversion/passthru), WASAPI exclusive

Network: Wired gigabit ethernet, Belden-M Cat 5, Netgear Nighthawk R7000 router, Cisco SG 300-10 switch, Netgear GS308 switch, Netgear R6400 router (for wi-fi access point and wired connection to AV devices)

Internet connection: Charter Spectrum, Arris cable modem, 31ms latency, 222mbps download, 11mbps upload, DNS,

Library: ~2090 albums (about 50/50 local/qobuz), ~24,770 tracks, ~300GB (on local file server)

Streaming service: Qobuz Studio Premier

Description of problem: Shuffle playing a bookmark. Roon endpoint stops playing, zones disappear, message says select a zone. After a couple of minutes, zones reappear, the previously playing zone is selected, the previously playing track is loaded in a stopped state. Pressing play resumes playback. This happened twice this morning, once at around 9:48 AM (playing Don Henley?) and again around 10:25 (playing Swing Out Sister?). Here’s the log (please remove link after you retrieve it).

(Link to logs removed by me. If you’re interested in looking at them let me know where to send them privately.)

Hi @SKBubba,

Is this just something that happened today or have you been experiencing this for some time?

During the time when this occurs are any devices showing up in Settings > Audio?

It started in the last week or so, after installing 571 I think. Have not seen this behavior before. Don’t know about devices in settings audio. Will check next time it happens.

Happened just now. By the time I brought up settings audio there were devices listed, and d10 had a red message saying ‘enabling’. Then all the devices disappeared. Then they were listed again, same message on d10. This repeated three or four times, and finally it got back to where it was and I could click play to resume playing. I think I also saw the red ‘enabling’ message on the core pc device during all that. (Note: all other devices attached to the endpoint pc except d10 are disabled in settings.)

Have you done any diagnostics like rebooting everything?

Yes. Was starting to suspect the d10, but it plays fine hour after hour with jriver and also works with qobuz desktop app.

Also, this glitch is back:


It seems like a less annoying version of the problem reported in this topic. The stopping/recovering happened frequently yesterday afternoon, and once or twice this morning. The rest of the day has just been delays between songs, tracks skipping (qobuz and local) a few times, and slow updates of the now playing screen. I still have the logs from this report if anyone from support is interested in looking at them.

Ok, possible progress. See this:

Disabling this “feature” (which involved editing the registry) appears to have roon operating normally again, at least for about the last hour. My guess is this was enabled by a recent Windows update that happened around the same time as the latest roon update.

If roon continues to operate normally for a day or so I’ll be back with an update and a more complete forensic analysis.

Ok, I suspect my problem was related to some recent windows change to how “modern standby” works. Windows does not have a way to control it, even though I had power settings set to never go into standby and to turn off the display after 30 minutes, and you can’t turn it off in the lenovo bios settings as far as I can tell. Apparently, when the screen goes off it enters this zombie “connected standby” mode even when power settings say never enter standby. Another clue was that going back to the office and nudging the core pc screen awake seemed to temporarily restore roon functionality.

I tried various registry settings, and nothing seems to work reliably unless you never allow the screen to sleep and I’m not even sure of that.

I got tired of messing with it and moved the core to a surplus windows desktop previously being used as a sql/file server for development work. It is decent spec with a fairly recent 7th gen i5, all ssd, etc. It does not have “modern standby”. Roon core is running like a champ all day long now, and the problem appears to be resolved.

My theory as to why JRiver worked is that it runs its media/library server as a service, whereas roon does not.

Anyone running windows core on a nuc, a notebook, or a 2-in-1 Surface Pro type pc (like my Lenovo X1 Tablet) or anything with a battery could have this problem. I think nuc has a bios setting to turn it off. To see if you could be affected, run ‘powercfg /a’ from the command line. If you see S0 “connected standby” as one of the available modes you could have this problem.

This is all just my theory based on limited knowledge armchair analysis and observation. I could be totally wrong.

Anyway, to quote a popular 70s movie, “All necessities provided, all anxieties tranquilized, all boredom amused.” For now, anyway.

1 Like

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