I can’t be sure if this is due to Early Access or not, so I’m posting here. I discovered this issue while trying isolate a problem where my Nucleus Plus had 30 second delays (or more) between playlist songs. This is repeatable on both my Nucleus Plus and my M1 Mac Mini, both on early access builds (1321).
In essence, it appears to be 2 problems:
- When tracks change, Roon processes library “profilestats” that are presumably related to both the current player profile and the completed song. Over time (just a few songs), the processing delays to do this get more pronounced. When I had my now-deleted original profile directing things (it was the primary profile on my account for years), the processing of profilestats went on for 30 seconds or more.
- That problem might not be so bad except that when music formats change between songs (from FLAC 192 to FLAC 96, for example), the Roon core seems to be blocked from doing many things (like loading the next song) until the database update completes. This does NOT happen unless the track formats change (the delays still happen, but they don’t block queuing the next song unless there’s a format change).
Steps to repeat:
- Create a playlist or queue from two or more albums (local or Qobuz) with different bit depths. All the songs should be in the Library.
- Reorder the playlist to alternate between formats for each song.
- Play the list, taking care not to just “NextSong” through each entry because that doesn’t appear to engage the profilestats the same way
- Watch log entries for music/profilestats and subsequent library endmutation entries grow longer. On my Nucleus+, these grew pretty fast. They seem to grow more slowly on the M1 Mac, but they still grow.
- Once the delays are long enough, you’ll be able to hear the delay, as well as seeing the Remote client go into a “waiting” state where the play bar busy-flashes as it waits to advance to the next track.
Other observations
- Rebooting the core resets the delays back to manageable (less than 1 second) levels.
- If a playlist item was added by an old (i.e. big and bloated?) profile, the updates can take more than 30 seconds. With a clean profile, they still climbed to more than 5 seconds in a couple hours on my Nucleus+. This was entirely dependent on which profile (bloated/old or new/clean) added the song to the playlist. Even with the same playlist.
- On the M1 Mac mini running as a dedicated core, for example, it only took a couple hours of music to get profilestats log time of 800+ms with subsequent endmutation time of 1500ms. That’s more than 2 seconds in total. The Mac itself doesn’t appear under any performance pressure at all (memory, disk, cpu, network all at very low utilization).
- I don’t think any of this happens if I just play a Qobuz playlist (where none of the tracks are in my library).
- Once blocking happens, lots of other weird timing problems manifest depending on which endpoints I’m using. It can, for example, make one of my AirPlay clients just stop between songs every time the format changes.
Both setups are running in clean network environments, using Ubiquiti infrastructure and wired endpoints. It happens with any endpoint (I’ve observed with RAAT connections to SMSL DAC, Matrix Element X2 DAC, and Devialet Phantoms).