MacBook Pro 2019, 2.8GHz i7, 16GB RAM
Mac OS 10.14.6
Roon version 1.8 (build 764)
Network Details (Including networking gear model/manufacturer and if on WiFi/Ethernet)
TP-Link Archer AC5400 over WiFi
Audio Devices (Specify what device you’re using and its connection type - USB/HDMI/etc.)
Roon Endpoint: iPod Touch 7th Gen > Chord M-Scaler
Description Of Issue
After booting Core, music playback is good for 2-3 hours until at one point on track change music stops playing. The playback head stops moving, but the play button icon is on “play” not “pause”. The audio source selection shows the selected endpoint “music playing” animation on the device.
File type doesn’t seem to matter so far.
Workaround I use is to quit and restart the Core app, as well as quit and restart the endpoint remote app. The endpoint does not reconnect with the core without restarting the remote app.
However, other remote apps (like on my iPad) successfully reconnects after Core app is restarted.
Hi @spektrograf and welcome to the Roon forum. For symptoms like this I’d usually suggest looking at the device power saving settings. Is there a sleep function that kicks in after 2 hours, e.g. a screensaver. While I’d still suggest you check that out, I don’t think it’s going to be the cause here. The “playing but not playing” behaviour suggests there’s something else amiss.
Thanks for the quick reply, Carl! (and thanks for the welcome!)
I checked both the iPod Touch (endpoint) and MacBook Pro (Core) and neither have such a function. iOS doesn’t seem to have a user-settable sleep function, and MBP isn’t set to sleep.
Minor detail, but forgot to add, when this issue occurs and I attempt playback (either via endpoint or Core) of any other track, the same result happens. The Roon UI on any device shows that the track is playing (animation and play/pause button is on “play”), but there is no sound and the playhead doesn’t move and is stationary at 0:00 point. I can move the playhead to another point in the track, and the UI indicates it’s playing but the playhead doesn’t move.
Additional setup detail…
Music library is an external Samsung SSD drive connected to CalDigit TS3 via USB. CalDigit USB is connected to MBP via Thunderbolt 3.
Update:
I’ve had music streaming for the last 8 hours or so non-stop from the Core to an Android LG V30 with no interruptions. So, perhaps the issue has something to do with the iPod Touch 7th gen as an endpoint, or the playback of high-resolution source files natively?
Roon does SRC when playing back to the V30 (via Android Audio at the endpoint), while the iPod Touch sends file native data stream to the Chord M-scaler (including DSD files).
Will experiment more tonight with the iPod Touch setup.
Update:
No need to reset Core when it happens. I just need to terminate and restart the remote app on the iPod Touch. Seems to happen more with DSD files. For a moment I could get it to happen repeatedly by playing a DSD256 file then pausing playback for several seconds. Upon hitting “play” to resume playback, it’s when the issue arises.
I tried with a DSD128 file to see if I could reproduce, but that didn’t seem to be an issue. Going back to the previous DSD256 album, the problem went away.
I’ve randomly had the playback issue you are having but it was from a core to another computer running hqplayer to a naa on a pi to a usb dac. All the times it happened it seemed to be network related… whether it’s buffering or cache problems idk, but something locks up and I have to kill the network connect or restart an app and it fixes it. Fortunately it doesn’t happen too often.
My core is on a Hackintosh sitting under the desk in my office with a plex server, roon server and file server I built 7 years ago, it runs 24/7. Everything is cat 6 back to a central switch. I only use WiFi for idevices and laptops. I’ve gone several months on 1.7 and not restarted the core.
I guess what I’m trying to say is that I’ve found the core when running the server only app, was pretty damn solid. I’d look away from the core and to the other bits connected for the cause of the problem.
Wow yeah, that sounds even worse than what I’m running into. So far it seems more related to the iPod Touch I’m running as the endpoint in having hiccups with some DSD files.
All-in-all, can’t complain much with 1.8 so far. So far so good, indeed.
It’s definitely specific to the Roon Remote app on iOS running on the iPod Touch. The issue doesn’t seem to be related to DSD files, since it just stopped playing on a 24/96 file. It also doesn’t seem to be related to the DAC, since at the moment I’m running the iPod Touch to a Wyred 4 Sound DAC.
To me, this sounds like network related (IP-Addresses change or network changes channel).
Why do you think so? Do you have other, not iOS based, remotes that don’t have this issue?
If yes, is this unaffected remote connected over WiFi, like the iPod, or wired network?
That’s interesting. I’ll start to track the network provisioning on the iPod Touch. Though that being said, if IP address changes or network changes channel, the Remote app would disconnect from Core, no?
In my error case, both Remote and Core shows playback on the endpoint as active—no disconnect state, but the playhead in the UI doesn’t move and sound isn’t produced.
Yes to both questions. I’ve long-play tested the Android Roon Remote app on my LG V30 and Samsung S10e—both connected via WiFi to the same network and they have yet to terminate playback after several hours—albeit they were playing back via onboard audio.
Today, I’ll try connecting the V30 to one of my external DAC’s to match the issue condition to verify that it’s not the end-point interaction with an external DAC that is causing the playback termination.
Looks like I figured out a short term fix for the issue. I turned off the screen auto-lock and I haven’t had the issue reappear.
Settings > “Display & Brightness” > Auto-lock > Never
It looks like it has something to do with how iOS handles background applications and the screen being active perhaps indicating that the app running in the foreground doesn’t get managed by the background app management process.
That’s my guess anyways. Though not ideal, it seems to have solved the issue.
