Post-startup Scan causes Roon to restart: Neverending loop

Core Machine

sonicTransporter i5 (no internal drive) running sonictransport v2.7
Roon Server v1.8 (build 790). Library is about 32K tracks.

Network Details

Switch: 3com OfficeConnect Dual Speed 16 plus
Router: SonicWall TZ300

Audio Devices

microRendu → USB → ifi nano

Description of Issue

I enjoyed flawless streaming since inception (Jan 2020) through 2021-05-14 evening. Became aware of this issue when I tried to use it the next day in the evening. The behavior I experience is that my Roon client (Android or Mac) waits for a connection; then, after a couple of minutes of “Scanning now …”, loses connection, and this behavior repeats itself in an infinite loop.

From the Roon log, there are numerous “dirty” references to items such as tracks. I started a ticket with Small Green Computer to get their impression of this.

Can you help me identify the root issue?

I managed to regain some control. After a startup, as soon as the menu became available, I went to Settings > Services and disabled Qobuz, which halted the scanning process.

With the Qobuz service (517 tagged items) and my single-path storage (32,373 tracks) disabled (altogether, my collection is piddly), I found that I could enable either one without consequence. With the Qobuz service initially enabled, enabling my storage was consequential. With my storage initially enabled, enabling Qobuz was not consequential, resulting in everything I was accustomed to having before, only now it is arrived at via a special “hand shake”. I now constrain scanning to startup only, which I am inclined to do when I 1) have new music I am ready to enjoy or 2) performance/responsiveness has noticeably declined. For now, restarting means temporarily disabling Qobuz until scanning is complete.

Hello Marc,

I’m very sorry to hear that you’re having difficulty with getting Roon to launch and scan your library. We definitely want to get you going again so you can enjoy your music.

We’d like you to reproduce the behavior and pull a full set of manual logs (i.e. the entire Logs folder) for us. We’ll take a close look at the last batch of logs in addition to the new set to see if they reveal the cause here.

Thank you for your help with this.

Thank you for following up, Jamie. I don’t know how to access a full set of logs from my sonicTransporter. It only provides a log via a Roon Server Diagnosic button. I have asked for that answer on Small Green Computer’s community. I will follow up when I have their answer. . . .

@salv0 Thank you for the update, Marc. I’m hopeful that you’ll get some advice on that soon. We’ll continue to monitor this thread for your response. :crossed_fingers:

1 Like

27 days later, I just received a brusk answer from Andrew:

That is what Roon is looking for.

I followed by asking if he is saying that this is all Roon should need. To reiterate, this is Roon running on SonicTransport i5 which seems to offer only one log view via a Roon Server Diagnostic button. Are you able to speak to the log files I should be able to see for Roon running on an i5? Perhaps the i5 Roon globs logs together into one view?

Hello @salv0

Can you update me on what type of issue you’re experiencing currently? I’m unable to determine if it’s with your library updating or something else. I’ll be monitoring this space for your reply.


When updating my library (ie, sync), Roon server crashes (my client loses contact with the core). Around one minute later, the core becomes available again and initiates library update once again, starting a never ending cycle of sync-crash-sync-crash. . . . I discovered that, if I disable the Qobuz service, sync succeeds, after which I can enable the Qobuz service without any negative consequence.

For now, my modus operandi is to configure sync to only occur on startup, and I manually update my library, after temporarily disabling Qobuz.

A behavior I have noticed with updating my library is that the file count progress is very slow initially. After several minutes the pace picks up. I suspect that most of the updating involves .m3u playlists because alphabetically, 36 of my 183 playlists have a name that starts with the underscore character (’_’), which precedes all of my 1594 track folders (I have almost 34k tracks). My impression is that playlist syncing is not thread-safe with the Qobuz service.

Additionally, when the sync count gets past 14, a large portion of my playlists have been processed and I found I can enable the Qobuz service and the ongoing sync will complete the 34K count without issue.

So much for Small Green Computer’s and Roon’s input. Abandoning my request. . . .

My workaround is to maximally limit autosync and temporarily disable Qobuz service while I manually trigger sync.

Hello @salv0,

I cannot even begin to apologize for having missed your replies to @jamie’s posts… I am so sorry! We definitely wouldn’t want to be the reason for you quitting Roon. On the contrary, it is our mission to help with any issue you might run into.

Since it’s been a while since your very last post, I was hoping we could ask for an update on your end :pray:

1 Like