Roon on Windows 11 loses music and audio device detection after a few days (ref#82VEXH)

Support
95

Hi @Dale_Rowney,

Thanks for the reply, I’m glad to hear things are still generally more stable than before!

The white entries are normal informational output (the column headers and the file paths the command printed). Only files with out-of-range dates were the concern, and removing the red ones was correct. You do not need to remove the white ones.

Beyond that, we took another deeper look at another fresh Roon Server diagnostic report, and see a slight difference in analysis versus what we’ve observed before.

The dominant finding: 84% of all diagnostic volume (what we analyze) about 959,000 lines, is the library query engine repeatedly re-sorting the same handful of albums

The albums caught in this loop are almost all very low internal IDs, likely the first albums in the database. This is a tight, CPU-bound thrash loop in Roon’s indexing layer that fires hard every time the server starts, then settles. The endmutation operations are taking 6–13 seconds each, where they should take milliseconds. This is what we saw as “Roon working at 95% capacity in the background,” and it’s the mechanism behind the eventual freeze.

The difficulty here is that we’re unable to see which specific albums are causing all the background work, although they do appear to be potential bootleg albums.

That said, Bootleg folders like Warren Haynes & The Midnight Blues Band - (1991)(26-9-1991) Wetlands,New York City,New York are exactly the over-long, near-duplicate names that bloat the indexes that are looping.

Shortening/standardizing those folder names is plausibly therapeutic, not cosmetic, and would very likely continue to help you overall.

This is the same underlying problem, not a separate one. It’s the artwork/album index serving stale cached associations because the index is perpetually mid-rebuild and never reaches a settled state. It corrects on click because clicking forces a fresh read. If the rebuild loop is resolved, this resolves with it. It is not a sign of further corruption.

Thanks for sticking with us for this long, Dale!

96

Hey Benjamin,
Thanks for your reply.
Yes things are slowly getting better.
Although it still takes 2-3 seconds when fast forwarding to the next song.
One breakthrough,is in Library-Settings-Unscheduled-Background,Audio Analysis has finally been able to process all 170,000 odd tracks.
Question: does it matter if I use roon during the scheduled time I have set ?
I listen to music to help me sleep and sometimes it might overlap with my current scheduled time (ie 1am to 9am)
That Warren Haynes & The Midnight Blues Band bootleg you mentioned I removed from my hard drive 6 months ago as you suggessted so I don’t know why it’s still a problem,(if it is or are you using it as an example).
Now that you mentioned that folder,how do I know when a folder is too long for roon to process it problem free ?
Previously I have encountered an error message of “destination file too long to unpack” when unpacking 7-zip files,so I just shortened the file to unpack it,then re-establish the name I originally intended.This was obviously before I knew of these problems,I’m guessing these are probably the infamous “red folders”.
Finally how many characters long can these folders be before I encounter these problems again ?
Plus where do I start counting ?
Currently all my music is in a music folder,then a bootlegs folder,then an individual folder as per the Warren Haynes boot.
So a definitive number would be a huge help.
A big test will be Microsoft updates and whether my library will still be there (currently my tech has delayed them).
As I said before,I love roon (when working) and I spent 5 1/2 years cataloguing everything so I’ll stick around until this is sorted.
Thanks again

97

Hey @Dale_Rowney,

No, it doesn’t matter, and you don’t need to change your habit. Scheduled Background Work isn’t a lockout, it’s just the window during which Roon is allowed to do heavy maintenance (audio analysis, metadata work). You can absolutely play music during that window. If anything, Roon prioritizes playback over background tasks, so seeking might feel a hair slower while analysis is running, but playback itself is never blocked. Since your big analysis backlog is now finished, there’s very little heavy work left to run anyway, so the overlap will barely register. If you ever find overnight playback feels sluggish, you could shift the window (e.g. start it later, or shorten it), but there’s no need to right now.

It’s being used as an example at this point, not a live problem.

Worth separating two different things here, because they’re being conflated:

The “red files/folders” from the PowerShell run were flagged for bad timestamps (impossible modified/created dates), not for name length. Those are the ones tied to the library-load crash.

The path-length limit is a separate Windows issue. Windows has a traditional maximum of 260 characters for a full file path, and critically, that’s the entire path, not just one folder name. That’s the same limit behind your “destination too long to unpack” 7-Zip error. When a path gets near or past that, both Windows tools and Roon can struggle to read the file.

“How many characters can the folder be, and where do I start counting?”

This is the part to be precise about, because the limit isn’t per-folder , it’s the total path length, counted from the drive letter all the way to the end of the file name including its extension.

So for a file like:

S:\Music\Bootlegs\Warren Haynes & The Midnight Blues Band - (1991)(26-9-1991) Wetlands,New York City,New York\01 - Track Name.flac

you count every character starting from the S in S:</code>, including all the backslashes, spaces, the folder names, the file name, and the .flac, and the whole string needs to stay under 260 characters (a safe practical target is to keep it under about 240 to leave headroom). With your structure of Music → Bootlegs → a long descriptive album folder → the track file, it’s the long descriptive bootleg folder names (full date, venue, city written out) that eat up most of the budget. Shortening those album-folder names is the highest-leverage fix.

Your instinct to be wary is reasonable given the history, but the thread’s diagnosis points away from the updates themselves being the cause.

What was happening before was that each Microsoft/Roon update triggered a library reload, and during that reload Roon hit the corrupted-timestamp file and crashed before it could finish, so it looked like the update killed your library, when really the update just forced Roon to re-read a library that had a landmine in it.

Now that the bad-date files are gone and analysis has completed cleanly, an update should be able to reload the library without hitting that crash. It’s not a guarantee, but the underlying trap that made updates so destructive has been removed, so there’s good reason to expect updates to behave far better now than they did over the past year.

Thanks again, Dale! :+1:
98

Hey Benjamin,
Thanks very much for your last email.
Very informative indeed,now I have a clear idea of folder length,it will certainly help for future set ups. I obviously had no idea about the file length,does that include the song title as well ? As some folders have medleys.
Does this mean if I shorten those file names in red to 240 characters as you suggest I can reintegrate these back into my collection ?
Once I find a folder up to 240 characters I can use that a template.
I haven’t been listening to as much music as normal as I’ve been watching as much of the World Cup as possible.
But I have had a couple of track unavailable prompts after deleting them,any reason why ?
Also if Roon has logged my entire collection why does it still take five seconds when fast forwarding to the next song.
I still have two huge issues to address but I need to talk to my tech about those and how to explain them to you,I think it best to get him to send you the next email as he will be able to speak computer directly to you.
Thanks again,
Dale

99

Hey @Dale_Rowney,

Thanks for the update, and glad the folder-length explanation was useful!

Yes, it’s the entire path length, so that includes the drive letter, every folder in between, the file name itself, and the extension. A medley with a long descriptive song title adds to that same 240 (ideally under 260) character budget just as much as a long folder name would. So if you shorten the album/bootleg folder name but leave a very long track title, you can still hit the limit, it’s the sum of everything that matters, not any one piece.

For the ones that were flagged red for path length specifically (the “destination too long to unpack” type), yes, shortening the full path down under the limit should let you bring them back in safely. Just a reminder that this is separate from the other red files we found with the PowerShell script (the ones with impossible timestamps), those needed to be removed or have their dates fixed, not renamed. Worth checking which category each file falls into before you reintegrate.

One thing to flag here: because the limit is on the total path, a “template” folder name that works fine in one location can still break the limit somewhere else if the track file name is longer, or if that folder ends up nested one level deeper. Rather than relying on a single example folder as a template, it’d be safer to keep each individual bootleg folder name short and consistent (e.g. artist, date, venue, no city/state spelled out in full) and then just check the total length for that specific file if it has an unusually long track title.

Same behavior we discussed back in May, when you delete the file from disk (or via Roon), Roon still keeps a record of it flagged as “unavailable” until you manually clear it. To fully remove it from the database, go to the track, open the three-dot menu, and choose Delete from Library. That’s the extra step that clears it for good.

This is likely the same indexing thrash loop we found in your last diagnostic, audio analysis finishing doesn’t mean that loop has stopped, since it’s tied to how the library engine is repeatedly re-sorting those long-named bootleg folders, not to analysis progress. Renaming the worst offenders (starting with the longest bootleg folder names) is the next real lever here, and should help this specific symptom.

No rush on the two remaining issues, happy to discuss with your tech directly whenever it’s easier to explain the technical side. Enjoy the World Cup in the meantime!

100

Hey @Dale_Rowney,

Wanted to follow up on this. Have you had a chance to try shortening the full path on the files that were flagged for path length, and to check whether any of the remaining red files were the separate impossible-timestamp ones we identified earlier? If the unavailable tracks are still hanging around after deletion, the next step is to use Delete from Library from the track’s three-dot menu so Roon clears them fully, and we are still curious whether trimming the longest bootleg folder names has reduced the five-second skip delay. Please reply with any updates or questions, and we can keep going from there.

Please note, if we don’t hear back from you this thread may close automatically soon. If the thread auto-closes and you need further assistance, please submit a reopen support request via the technical support help form below and specify that the issue should be reopened. Thank you.

101

Hey Noris,
Thank You for your email
As for shortening those faulty folders,no.Two reasons,being watching heaps of world cup games,but mostly waiting Roon to reappear after microsoft updates.
I still have two huge problems as I’ve explained to before,every single time Microsoft does an update Roon tells me “I have a problem loading my library”,then I need to visit my local computer store to have a tech set up Roon again,which costs me money,and has been for over 10 months.So until that is sorted those folders can wait.
The other massive problem is when Roon first disappeared and the tech reinstalled Roon I lost 5 1/2 years of work rearranging the individual songs into their correct folders,naming files and dating them etc.I have no computer knowledge so I don’t know how to maintain these changes,but that’s for another visit to the tech,which I’d likle to tie all things together,hope you understand.The guy that initially set Roon up for me has moved interstate and the hi-fi store has shut down,bummer.
So I’m struggling as you can see.
The 240 characters makes perfect sense and all I can do is remember that for subsequent downloads.
Having said that I know I have other folders that are way longer than the “red” ones,go figure.
Now onto deleting individual songs,I know of three ways.
Click 3 dots far right of song title - Edit - Delete track
Or right click play character prior to song title which highlights the song - 3 dots - Edit - Delete track
Or instead of deleting track individually
I press 3 dots underneath album title - Edit - Delete Album - View Items - then select items I wish deleted.
Let me know if that is the correct way,they all seem to work for a few weeks,then suddenly it doesn’t,weird.
I know it’s a long read,but I’ve invested way too much time and effort,let alone money to walk away and I do love Roon when it works,until the next update that is.
Any help on these would be greatly appreciated.
Dale

102

Hi @Dale_Rowney

Answering your questions, and there’s actually a shortcut here that solves the exact problem you care most about, so please read through before deciding this can wait.

On deleting tracks and albums: all three of your methods are correct, valid ways to remove things in Roon:

  1. The 3-dot menu on a track, then Edit, then Delete Track
  2. Selecting a track’s checkbox, then the 3-dot menu, then Edit, then Delete Track
  3. The 3-dot menu on an album, then Edit, then Delete Album, then View Items to pick specific tracks

The fact that they “work for a few weeks, then suddenly don’t” isn’t you doing anything wrong. It lines up with the same library-reload problem we’ve been chasing this whole thread: when Roon crashes and has to reload your library, edits that only live inside Roon’s own database (not written into the file tags themselves) can get rolled back or lost.

On losing 5.5 years of organizing work after the reinstall: this is the most important thing in your message. Roon has a Backup feature (Settings, then Backups) that saves your entire library, including all your manual organizing, naming, and dating, to a file your technician can restore from instead of rebuilding from scratch. If backups weren’t already turned on and pointed somewhere other than your C: drive, that’s very likely why a reinstall wiped years of work instead of just restoring it. Please have your technician check this before anything else. If it’s set up correctly going forward, a future reinstall becomes a 10 minute restore instead of losing everything again.

On the ZZZZZ folder, and why it shouldn’t wait: we understand you’d rather deal with one thing at a time, especially with the World Cup on. But we want to be direct with you: we think this folder is the actual cause of your biggest complaint, the “problem loading my library” message every time Microsoft updates. It’s not a side task, it’s very likely the fix for the expensive part.

The good news is this doesn’t need a tech visit or any technical skill. It’s one drag and drop:

  1. Open File Explorer, go to your S: drive, then the Music folder
  2. Find the folder named ZZZZZ
  3. Cut it (right-click, Cut, or Ctrl+X)
  4. Paste it anywhere outside that Music folder, your Desktop is fine

That’s it, no deleting, no risk to your files. If you’d rather not touch it yourself, that’s completely understandable, just let your technician know this one folder move is the priority next time you see them, ahead of the path-length cleanup.

We know this has dragged on for months and cost you real money. Let us know once the ZZZZZ folder is out and we’ll keep an eye on things with you from there.