I’ve seen reference to metadata breaking the Discover function. I believe I have this issue and Discover breaks only when I enable my largest music folder in Settings → Storage. How can I identify the culprit? Is there an error in a log file that will help me identify the tag that is creating the problem?
I’m not sure about logs but I can tell you that when this happened to me it was the Genre tag causing the problem.
I had some genre names that I made up myself that Roon didn’t recognize.
I was able to spot the offenders because they were the only genres that didn’t have a photo associated with them in Roon.
While I was trying to figure this out support suggested I change Roon settings to use Roon genres only.
With this setting Discover would work. It was only when set to use file tag genres that Discover wouldn’t work.
After changing the metadata tags for the problem genres to something less esoteric Discover worked again.
Hey @John_Barrar,
I am so sorry it’s been so long since you have posted about this issue. Our technical team was not notified, unfortunately, as the topic was not created in the Support category. I’ve moved it there, so it is now in their queue.
While they get back to you, can you please offer these details?
Roon Core Machine
Include your operating system and machine info (Model, CPU, RAM)
Networking Gear & Setup Details
Your network gear (model of routers/switches) and if on WiFi/Ethernet
Connected Audio Devices
Specify what devices you’re using and their connection types, like USB/HDMI/Chromecast, etc.
Number of Tracks in Library
Tell us how large your music library is, eg. “30,000 tracks”
Description of Issue
Tell us about the problem you’re having in as much detail as possible. Screenshots are always appreciated!
Thanks a lot 
Roon Core Machine
Synology 918+ 8GB RAM with Roon Core running on M.2 storage. Performance of Roon on M.2 storage has been excellent outside of the Discover function even with the limited CPU in the Synology NAS. Using the RoonOnNAS project.
Networking Gear & Setup Details
Roon Core is wired via Ethernet to a Netgear Orbi router with gigabit FIOS service.
Connected Audio Devices
Roon endpoints are all WiFi - Some using Roon Ready and others connected as Roon tested. All are linux based.
Number of Tracks in Library
Large ~150,000 (hence the difficulty finding the track that is breaking Discover)
Is there anything else that I can provide that might help determine a solution?
Hey @John_Barrar,
I’ll re-share what @Placebophile mentioned earlier, as I think it’ll be a good thing to test next:
Do you share a similar experience? If possible, can you recreate the issue and share a more specific date and time when the issue occurs? I pulled a fresh diagnostic report from your core device, but wasn’t able to find anything specific.
With that, we did see a handful of issues related to Google Cast devices, as well as the Nest Hub, that are flooding mDNS into the network and maybe confusing Roon and/or the router. Could you please temporarily power off your cast devices.
If you have access points within your local network, try using just the main router WiFi instead, if possible. Access points and mesh networks can cause issues with Google mDNS.
Let me know, thanks @John_Barrar!
I did read the genres suggestion, but Roon was already set to prefer Roon genres only. Use genres from Roon’s metadata database is set to yes and Use genres from extracted file tags is set to no. In the log, I always get the same error when clicking “Discover”:
09/08 14:05:46 Critical: scx: System.Exception: can’t convert NullDate of 2001/169/0 to DateTime
at Sooloos.NullDate.ToDateTime(Boolean start)
at Sooloos.Broker.Music.DiscoverResult.Discover_GetAlbumsReleasedInThePast(Library library, Int32 maxretcount)
at Sooloos.Broker.Music.DiscoverResult…ctor(Library library, GetDiscoverDataParameters p)
at Sooloos.Broker.Music.LibraryApi.<>c__DisplayClass416_0.b__0(ClientContext clientcx)
at Sooloos.SynchronizationContextThread._Dispatch(SendOrPostWrapper& ret)
The “can’t convert NullDate of 2001/169/0 to DateTime” makes me think I have a date metadata tag in a file somewhere that is malformed or corrupted. If I disable one of the four places that I am scanning in my library, the problem goes away and Discover works just fine. The problem is that there are thousands of tracks in the offending folder structure (over 150k). It’s the largest of the four folders that I have music stored in. There is no way to look at every music file individually. Are there any utilities that I might be able to use to scan the files looking for the malformed metadata entry? I have a mix of PCM and DSD files in that structure as well. Because of the error and the ability to make Discover work by disabling one storage location, I’m not sure if DNS is the problem.
Hey @John_Barrar,
Thanks for the update!
As a next test, could you please make a fresh backup, then disable all the non-problematic watched folders, and then perform a library clean up from settings>library?
This will temporarily remove all the other watched folders from your database, leaving the one folder with the issue file. After performing this, I’d like to see what shows up under settings>library>skipped tracks, if you could share a screenshot.
Another potential option to test would be to change both the original release date and release date under settings>library> import settings to Prefer Roon (or, Prefer File depending on what setting you have enabled.)
In the meantime, I’ll be taking this issue to our development team to discuss further. Thanks!
I started with setting the original release date and release date to prefer the file (they were set to Roon). Once it completed, I tried Discover and got the same error. I then set original release date and release date to prefer Roon. Same error. I then disabled the three library storage locations that were not causing issues and performed a library clean up. Once that completed I checked for skipped tracks and the following was displayed. It’s all “Unreadable Image File” errors. 848 of them when I export the results to Excel.
Hey @John_Barrar,
Thanks for the update! Please test out removing the following tracks and let me know if the issue persists:
Gregorianischer Choral - Death & Resurrection - 14 - Dominus in Sina (AL).flac
Lyle Lovett - 13 - The Girl in the Corner (Hidden Track).flac
Linda Ronstadt/Cry Like a Rainstorm - Howl Like the Wind/12 - Goodbye My Friend.flac
Pavarotti-Domingo-Carreras/Carreras Domingo Pavarotti In Concert - Zubin Mehta/17 - Encore - Nessun Dorma (All).flac
Straight No Chaser/SNC Mix/01 - Track 1.flac
Gregorianischer Choral - Death & Resurrection - 14 - Dominus in Sina (AL).flac
Those were good catches. All files with no tags at all. I moved them away from the library and forced a rescan and then did a Library cleanup. No effect on the Discover error in the log file, “09/11 20:06:46 Critical: scx: System.Exception: can’t convert NullDate of 2001/169/0 to DateTime.” Those files were actually in a storage area that doesn’t cause Discover error out. Still, good to find those and clean them up. Thanks for continuing to help me track this down!
I went through and cleaned out any files that Roon reported at “Corrupt” as well, using Focus on the Tracks listing. No change. I also removed all of the “eaDir” directories from the music storage locations, as Roon was scanning all the files in those Synology specific directories and picking up at least some junk like unreadable artwork. It’ll take some time for the library to finish processing those changes and I’ll report back if it helps.
Nope, none of that worked. I think I have a track with a bad date in a tag somewhere. Is there a utility I could use to scan the tracks on my drive to look for that “2001/169/0” value in a tag?
I still use JRiver , the search function would find that sort of error or a custom view listing that Tag in sort order would highlight a few things
Far be it from me to suggest a 30 day trial !! You may even get to like it 
That’s a good idea to have a look at the tag contents. Hopefully I’ll be able to track it down in their interface. Here’s hoping! Will report back…
No luck. I went through every track in the offending storage area in JRiver and cleaned up any tags that looked “off,” especially the dates. Still getting the same error message in the log when attempting to open Discover. I’m definitely benefitting from a little cleanup in my library but I sure wish I could figure out what is causing Discover to quit.
Certainly there’s a utility that would let me query the Roon database looking for this value?
Hey @John_Barrar,
Our team was able to confirm that your issue is indeed one that we have identified on our end, and are actively working on a fix for. That said, there isn’t currently much of a work around, unfortunately -
As of right now, you may need to manually set aside your library and move it back incrementally until the offending record is found.
You may also find helpful tools by testing out Dbpoweramp, as many users use this third-party app to organize and edit metadata.
Outside of that, I will keep you updated as things progress on our end.
I removed the storage location that was a problem and added it back in sections. This seemed to work. Even after adding all of the music back, in about 12 different storage locations, Discover was working. All of the tags had been read in my files and things looked great. It was only after the identification phase, where Roon identifies albums by scanning file and directory names, that the error returned. It seems that the problem is not a tag inside a file, rather it’s in the metadata pulled down from the Roon online database while identifying tracks. Because this process is done “after the fact” when files are added to Roon, there’s not likely any way to identify the offending record in real time. The bad metadata isn’t in my file, as the problem didn’t show up until after all off the tags had been read. It took almost 48 hours to show up, when the identification phase had completed. This is really disappointing, as Discover is one of the advantages of Roon with a large library.
I don’t know if an update was released, but Discover started working in my library. Not sure why or how, but it’s wonderful to have the functionality back!
1 Like
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.