I have an unusual problem with Roon frequently not finding the first track on some albums after the music is copied to the hard drive of the library.
My process is to rip/download music to a main editing machine where I organize the music and perform any required tag edits. I then use a robocopy script to copy the music from the main machine over the network to my server running roon core. For some albums (usually HIRES ones downloaded from HDTracks), Roon finds the new tracks, but fails to recognize track one. This usually means the album isn’t properly identified.
If I go to the location on the roon server and delete track 1, then copy it over by hand again, Roon recognizes it and all is well. So I have this as work around, but I’d like top understand if there is something I am doing in the process to confuse Roon: the whole point of the robo copy script is to not have to copy things by hand.
There is no corruption of the copied files. I know this because when I fix the problem buy hand I simply copy the file to my desktop over the network, delete it on the share, and copy the same file back. When it reloads everything is fine.
The RoboCopy command is:
robocopy d:\musicflac \htpc01\musicflac /MIR /W:5 /Z /xoZ
where d:\musicflac is the source location on the main machine and \htpc01\musicflac is the shared HD on the roon server.
Hi @Dan_Petit ---- Thank you for the report and sharing this observation you have made with us. The insight is always appreciated!
Moving forward, when you make this observation does the “first track” by chance end up in “skipped files” and if it does, what is reasoning for the content to be skipped?
Additionally, while I am not personally familiar with RoboCopy I did do some research just to see if anyone else has experienced this behavior outside of our application and this sounds like the same experience you are reporting. A bit out of date, but I want to get your thoughts based on the symptom you are describing.
“Im copying files over using Robocopy and its copying but everytime there is a corrupt file it waits 30 sec. Does anyone know how to stop the 30 sec wait? I dont want to do anything that will end the copy, I just want it not to wait 30 sec. Thanks.”
Like I said, if I copy the file to my desk top, delete it in its original location, and copy it back, Roon gets it right.
This only seems to happen with large (HD) files.
Is there a way to make roon’s new file detection manually triggered? I suspect it is trying to read the file before it is done copying. Robocopy is effective at detecting differences and copying new files over, but it is a generally slow copy (slower than using file explorer in windows manually.
Looks like Robocopy is using an unsafe method to copy files. A safe file copier copies to a temporary file, and then atomically renames that temporary file to the target file path. That way, only complete files are visible at the destination.
It’s not that Robocopy was unsafe - it was perhaps a bit too safe. The /Z option I used is designed to make large copies resumeable in case of a lost connection. I suspect this was making Roon commit a false start when it detects new files (the first new file in particular) when the files are quite large. Roon tries to load the file before it is completely transferred.
Removing the /Z option seems to have resolved the problem.
