Tracks showing up as corrupted in Roon also do not indicate any amplitude variance on the progress bar as normally is the case. This is not the only issue I am having. I just imported several CD’s and as you can see from the screen shots:
The CD’s show up as duplicates.
The songs are split between the duplicates.
All of the songs from the CD are not present, even between the split CD’s–some are omitted!
Try right clicking the two Collaboration albums, then click Edit at the top right and select Merge Albums.
That should combine the two albums. Now use the search feature to search for specific songs that are missing. My guess is that they are in a different “album”. If you find them, use the Merge feature again.
See how that works. Remember, album identification isn’t always perfect. Sometimes you have to help it along.
I believe I’ve got this narrowed down to a bug in the code that detects whether a file has changed, which I introduced while trying to fix a different problem on February 8th. We released build 200 on the 9th, so this has actually only been in stable Roon for that one build, and a fix should be forthcoming in our next release.
@Lee_Allen, it’s likely that the album identification issues are at least related to this problem, because the code that identifies albums has a harder job to do if some of the files are missing or appear to be corrupt.
My apologies for the trouble, and thanks for bringing this up so that we can fix it.
Happy to hear my issues may have brought this to light so it can be addressed sooner rather than later. Any idea when you will have it fixed? Although I am ready to get on with ripping the ~150 additional CD’s required to complete my library, I am not inclined to rip/import any more until this issue is fixed–it takes too much time to fix each import. Thus the timeframe for the fix is important to me.
Nope - I have always used this method, and it causes false flagging of I/O errors in 1.3. Best workaround, until the fix is deployed, is to stop Roon Core before copying across files/folders into a Watched Folder, then restart the Core, and Roon will read the files without problems.
I’m not speaking of moving files within the watched folder; just moving them from staged to watched.
Moving files (OS wise) is quite different from coping them.
And I wondered if you had seen this issue when you move rather than copy them from staging to watched?
In build 200 you are likely to see this problem any time there is more than about 2 seconds between a file being ‘created’ in the watched folder and the last write to that file. Exactly whether this will apply to the various move/copy/rename operations on different operating system and hardware combinations is hard to determine without testing. I’d guess that moves are much less likely to trigger a problem than copies, because much less data needs to be written to the hard drive for a move than a copy, but I’m sure a sufficiently slow move could still cause a problem.
OK, I usually drag and drop files/folders between two open instances of Windows Explorer. This means that if the destination is on a different drive from the source, then the files/folders will be copied. If the destination is the same as the source, they will be moved.
And since my staging is done on a drive that is not the same as the destination (the Watched folder on another machine entirely), then my files and folders are always copied, not moved.