That folder appears to be left over from a previous auto-update of Roon 1.2, I’m not sure why it’s still there. I don’t think it’s doing much harm, but closing everything Roon related on that machine and deleting “C:\Users\George Shin\AppData\Local\RoonServer\Application\100200161” is probably a good idea.
Hi @rolski ----- Thank you for chiming in here and sharing your feedback with me. Can you drop some logs here from your core machine in a dropbox link? We’ll gladly take a look and see if we can determine what’s going on here 
-Eric
I am happy to report that I have a confirmed fix for everything with things that look like this in your log:
This will be in our next release, whenever that is. In the mean time, that crash is caused by a piece of our code that attempts to ignore playlist files that are autogenerated by CD ripping software. If you happen to both have this problem and are not actually using playlist files, you can fix this by turning “Import Other Playlists” to “Off” in the settings for your watched folders.
Nicely done! Thanks for the effort.
For now, rather than trying to a la carte the affected playlist files by getting them out of the way from being scanned, instead i’ll follow the suggestion to unset the global option to not import foreign playlists, until next build with fix comes along.
Quick question.
Once this option to ignore the playlists are set, then what happens, that causes rescan to occur, i assume removing those other playlists from Roon’s knowledge.
And after the fix, i turn back on the option. And simple rescan will then bring those other playlists back into Roon.
Yes?
Changing anything at all in that settings page causes Roon to rescan. The playlist import setting should be included in that, and work as you’ve described.