· Music won’t play or issues with my library
· Local files won't import or appear
· I/O failure on Roon imports with QNAP NAS
· The problem is NOT my router, storage or memory. This has all been checked this morning by QNAP. The problem is with ROON.
I just moved the 7+T of music from the internal 8T hard drive on my sonic transporter to a qnap nas. All of the music is there. Qnap remote accessed into my computer for customer support and went through everything. The music files are NOT corrupt as all of the files we checked played in apple music when clicked. They are all on the NAS.
Roon has decided that over 11K tracks are I/O failure and some as corrupt. Same files on the internal 8T sonic orbiter drive. This is where the music was transferred from. Just to double check I also tried to restore from the roon back up. Same thing.
This is really frustrating. I have restarted Roon, the nas and the sonic transporter multiple times. I even restarted my router and modem for completeness. Nothing has changed.
I have the same issue when I do massive operations. Try to do it in batches. For example I want to tag 1000 files, move them to a temporary folder with my own naming schema and then move each album to the appropriate final folder.
With Foobar2000 and Directory Opus it’s a matter of minutes. BUT Roon will fail because during tagging it will start the Background Analysis and then when it will reach the last files it won’t find them and show I/O error.
So I have 2 choices. If the files are too many I shut down the server and do my thing or I do it step by step waiting Roon to finish each job.
Hi @david_klipper,
Thank you for your post.
We’ve taken a close look at Roon diagnostic logging for your account. Fortunately, the actual storage mount looks healthy and Roon doesn’t have issues accessing files in general.
However, there are 5,706 IoFailure events that collapse to just 543 unique files. These files all seem to sharre a common topological nomenclature: they live in directories ending in trailing spaces, elipses, or dots.
There are 44 folders total that contain that naming convention.
Here’s an example with some actual location anonymized:
`07/12 10:57:22 Warn: [storage] [directory] Failed to extract audio format from ‘/mnt/RoonStorage_xxxxxxxxaaaaaabbbbbbccccccddddd/C/Creedence Clearwater Revival/1970 - CCR /4-04 Ooby Dooby.flac’: IoFailure
Try deleting the trailing space on the above Creedence folder and forcing a rescan within Roon Settings → Storage.
We’ll start there and watch for your reply. Thank you!
Hi @david_klipper,
The logs we just analyzed were from yesterday, not current to what you just posted. Let’s take another look and we’ll respond again shortly.
Where do I find this trailing space?
What do you mean? I am not sure what to do.
Thanks
So I looked and changed things.I restarted roon. My system states no skipped files at this point, although the blue wheel of death is still spinning.
My storage says 136K+. My question? If the music on my Sonic transporter hard drive states 143K+ tracks, why is the NAS only showing 136K? Where are the other 7K
Roon is different from other music SW. It’s not a simple player but an encyclopedia that pulls information from Internet. So it needs time to do it correctly. When you make massive changes you have to leave it for a few minutes to do it’s job. If you make a lot of things it will stuck.
I gave you an example. Tag files, move them in to a new location and then arrange them in to their final destination. With F2K which is a simple but powerful tool the job is done in seconds because the I/O operation is instant and it has NO other job to do. Tag and write to filesystem. Move the file and BOOM!!! It’s ready.
BUT Roon has to scan the audio fingerprint of the “new file” and download information from the Internet. So if you have 1000 files and move them, the SW will read the first 10-20-100 depending on your processing power and HDD speed and then it will stuck because the remaining are missing. So you will have to move them, wait for the SW do do the magic and then act again.
That’s why when you restarted the server it found the files. Because it started a whole new session and scanned the HDD from the beginning.
Hey @david_klipper,
Thanks for your patience, and good news to start with: your logs confirm the storage mount is healthy and Roon Server can reach the NAS fine. What looked like one big problem is actually two separate ones, which is why it’s been so confusing.
1. The “I/O failure” folders, this one is now fixed. These weren’t corrupt files at all. Your music lives on the QNAP over an SMB/CIFS network share, and SMB quietly drops trailing spaces and dots from folder names. Your old internal drive kept them, so when Roon asked the NAS for a folder like 1970 - CCR (note the space at the end) or …disc 1. (ending in a dot), the NAS couldn’t find an exact match and reported an I/O failure. Every one of the ~57 affected folders ended in a trailing space, dot, or ellipsis.
The important part: after you cleaned up those folder names and rescanned, the failures stopped completely. Your logs from that point forward show zero I/O errors, so that batch is resolved.
To find any remaining ones, in Windows/File Explorer they’re hard to spot by eye, the giveaway is a folder that sorts oddly or a name ending in a space, dot, or “…”. Renaming to remove the trailing character and rescanning in Roon Server → Settings → Storage is all that’s needed.
2. A set of MP3 files flagged as corrupt, this is separate and still needs attention. About 580 files, all MP3s, are in normally-named folders and are being flagged as corrupt by Roon. These have damaged file headers. They’ll often still play in Apple Music because Apple’s decoder is more forgiving, but Roon’s analyzer rejects them. Renaming won’t fix these, they’ll need to be re-ripped or re-downloaded. Examples include albums under Michael Jackson (HIStory), Elton John (Breaking Hearts), and Little Richard.
On the missing ~7K tracks: the failures above account for a good chunk of the gap, and some of the difference was likely just Roon still finishing its scan when you checked. Now that things have settled, could you check your track count again and let us know where it lands? That’ll tell us if anything is still unaccounted for.
Once you’ve re-ripped the corrupt MP3s, you should be in good shape. Let us know the current count and we’ll take it from there. 
Hey @david_klipper,
Circling back on this, have you had a chance to recheck the track count now that the folder-name I/O failures have been cleaned up and the library rescan has had time to finish? We also asked about those roughly 580 MP3s that Roon is still marking as corrupt, since the next step there is to re-rip or re-download them rather than renaming the folders. If you’ve got an updated count or any new findings from the bad MP3s, let us know and we’ll pick it up 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.
The track count is still missing over 7000. I have no idea where they are or which tracks, until I go to look for something I cannot find. The library is not showing any skipped files. There must be a way to find them.
Hi @david_klipper,
Good news: those 7,000 tracks aren’t lost. They’re still on your original sonicTransporter drive, they just didn’t make it across to the QNAP during the copy, for the folder-naming reason we covered above. Since the source is intact, we can find exactly which files are missing and get them over.
Since you’re on a Mac, here’s the cleanest way to do it without hunting file-by-file:
1. Mount both drives in Finder. In Finder, choose Go → Connect to Server (⌘K), and connect to each as a share, your sonicTransporter music folder and your QNAP music share, so both are open and visible.
2. Manually compare the two, or, let a comparison tool find the gap. Install FreeFileSync (free, has a native macOS version). Point the left side at the sonicTransporter folder and the right side at the QNAP share, then click Compare. It reads both and should show you every file that’s on the sonicTransporter but not on the NAS, that list is your missing ~7,000 tracks.
3. Manually copy just the missing ones, or, Click Synchronize in Mirror mode (left → right) and it copies only those files over.
That re-copies the files that failed the first time. The handful with problem names (trailing space, dot, or …) may error again on the way over, if so, FreeFileSync lists them by name, and fixing that small set at the source before re-copying will clear them. This is also a good moment to make sure the copy is going over SMB as-is; macOS can be finicky about those trailing characters too, which is part of why they dropped originally.
When it’s done, force a rescan in Roon Server → Settings → Storage and your count should climb back toward 143K.
(So it doesn’t get lost: the ~580 corrupt MP3s are a separate bucket, those are on the NAS but need re-ripping, not re-copying.)
Give the compare a shot and let us know what it turns up. 
Well that did not work. In forcing the rescan of the system, it seems that roon has decided to delete the majority of the 143K tracks that were on the sonic transporter. Go Roon Go!!!
Where do I find the 580+ corrupt MP3’s to know which ones they are and fix?
Hi @david_klipper,
First, the part that matters most: nothing has been deleted. I pulled your current Roon Server logs, and your library is sitting at 136,253 tracks across 8,284 albums right now, and it’s been steady there for days. A rescan never deletes files from your drives; it only re-reads what’s already on the storage. So the music is all still there.
Here’s what actually happened on the 24th when it looked like everything vanished:
Your music lives on the QNAP as a network share (SMB/CIFS, at \10.168.168.113). Every time Roon Server restarts or you force a rescan, that share needs a few seconds to reconnect. During those seconds the logs show the share go to DriveNotReady, then DirectoryNotReady, and while it’s reconnecting the library momentarily reads 0 tracks. The instant the share is back, the count climbs straight back to 136,000+.
I can see this exact pattern happen five separate times on the 24th alone (and again on the 21st, 22nd, and 27th). Each time the count dropped to 0 or a partial number, then recovered to ~136,232 within about two minutes:
Two more pieces of good news from these fresh logs:
The I/O-failure problem is fully resolved. After the trailing-space/dot folder names were cleaned up, the failures stopped completely, there are zero I/O-failure events in your current logs. That whole batch is behind you.
The mount is healthy. Roon is reading and playing files off the QNAP without trouble, you’ve been streaming across your Office, Bedroom, Garage, and Rendu zones throughout this period with no storage errors.
On the track count (136,253 on the NAS vs. ~143K on the old sonicTransporter): that ~7K gap is still just the files that didn’t make it across during the original copy, the folder-naming issue we covered earlier, not anything Roon removed. The FreeFileSync compare from my last message is still the cleanest way to see exactly which files are on the sonicTransporter but not yet on the NAS, and copy only those over.
On the corrupt MP3s you asked about: the quickest way to see the exact list is right inside Roon, open Settings → Library and click into the skipped files view. That lists every file Roon couldn’t import along with the reason for each, so you’ll have the precise set to re-rip or re-download (renaming won’t fix these, their file headers are damaged, even though Apple Music will still play them).
Bottom line: your library is intact at ~136K, the I/O errors are gone, and the only work left is (1) copying over the ~7K files that never transferred and (2) re-ripping the handful of bad MP3s from the skipped-files list. Have a look at that list and the FreeFileSync compare, and let us know what they turn up we’ll take it from there.
There are NO files in skipped files.
The files that were on the SonicTransporter have vanished. This has NOTHING to do with turning the unit on/off or doing a rescan. They are NO longer to be found. I have no idea where they went.
Therefore, trying to perform what you keep mentioning cannot happen.
The roon back and forth customer service is horrendous. We have accomplished nothing lately except getting me frustrated.
Hello @david_klipper
We went back and pulled fresh diagnostics again, and this time also compared them against an older diagnostic snapshot from about three months ago, to get a fuller picture of what’s been happening with your library over time. A few things came up that we want to share directly, along with some questions to help us narrow down exactly what happened.
First, going back to April: we found that on April 19, your internal drive’s library dropped from 143,735 tracks to 0 almost instantly, then came back partway to 131,725, about 12,000 tracks short, and stayed stuck at that reduced number for close to two full days. It only recovered fully, back to 143,735, after the Roon Server was restarted and did a complete rescan. This tells us the internal drive itself was already having some kind of intermittent connection or reliability issue well before you moved to the QNAP, not something Roon caused.
Second, on the current side: right now, Roon Server’s own diagnostics don’t show that internal drive connected at all, only the QNAP share shows up. That doesn’t necessarily mean the drive is gone for good, it may just not be visible to Roon at the moment for a number of reasons, so we don’t want to assume anything either way.
To help us figure out exactly what’s going on, could you please answer a few questions:
Is the original internal drive still physically inside or connected to the sonicTransporter, or did you remove or disconnect it at some point?
When you moved your library over, did you copy the files across the network to the QNAP, or did you physically move the drive itself out of the sonicTransporter and into the QNAP enclosure?
Did you notice any errors, disconnects, or warnings involving that internal drive around the time of the move?
If the original drive is still accessible in any way, even outside of Roon, could you please check whether the files on it still open and play normally? Given the instability we found in April, we want to directly confirm whether any files were affected, rather than assume everything on that drive is intact.
Once we know the current state of that drive and how the move was actually done, we’ll have a much clearer path to finding those missing tracks and confirming whether anything needs to be re-ripped or replaced.
One important clarification throughout all of this: Roon itself never deletes files from your drives. Rescans and reconnects only read what’s already there, they don’t remove anything. Whatever happened to the missing tracks, it happened at the storage or hardware level, not because of anything Roon did.
