For what it’s worth, I’ve removed all of the ‘unidentified’ tracks from my library 8 days ago and I’ve not experienced the excessive latency since.
The vast majority of the tracks had solid metadata populated and Roon displayed it all but still labeled them not ‘identified’.
“Unidentified” means that it did not find a matching album identity in its online metadata sources. That can still happen even if the file tags are fine. In this case, it still periodically checks if the album was added to the online sources, and apparently excessively so, which seems to be what causes the issue.
Right, but it’s only recently become an issue. The tracks have been in the Roon library since 2017 or 2018 but only the past few months was I even aware of the load it placed on Roon latency. Seems to be a relatively new mishandling of unidentified tracks.
Yes, I know, somehow it has become more of a resource hog when doing this. I’m just saying what unidentified means, and that it’s not directly dependent on file tags, and that hasn’t changed.
Yes its gotten worse and more people affected. it reared its head last December with something they changed to improve slowness with larger libraries. But there is also issues with Sonos playback causing it for some.
Ok. Thanks. And here I thought ‘unidentified’ was pretty self explanatory.
Well, you said it happens despite the files having tags, and I’m just saying that this is not the decisive factor.
Just to coordinate. I’m sure this is the same issue:
I think we’re talking past each other. I don’t use Roon tags, if that’s what you mean by tags. If you mean file metadata stored in the MP3 or FLAC file I think it may be confusing to others to refer to these as tags in the context of Roon.
My files have complete metadata, no Roon tags, I haven’t used Roon tags to date. They are simply ‘unidentifed’ as in not a match for any of the metadata services Roon employs.
Since deleting the files, the Roon metadata gremlin has not surfaced. I’m back to normal listening…
Peace
I mean file metadata, which is widely referred to as file tags, decades before Roon existed, e.g., by the Roon documentation
As well as the various software that is used to write metadata to audio files, such as mp3tag. I doubt that this confuses many people.
I understood that.
This is exactly what I said. And I said it only because you had said, „The vast majority of the tracks had solid metadata populated and Roon displayed it all but still labeled them not ‘identified’.“
This read as if you might have thought that there is a direct relationship between file metadata and the identification status, so I tried to explain that there isn’t, just to avoid confusion.
@James_I suggested my problem is the same, guys am I in the same boat according to you?
Hi All,
Thanks again for all the detailed reports and analysis. What you’re observing is technically expected behavior—Roon’s metadata indexing process is designed to ensure accuracy and completeness, and during these operations, resource allocation may temporarily impact system responsiveness, especially in large libraries.
We recognize that this can affect certain setups, and our product team is aware of the performance considerations tied to metadata updates. However, this is not a support-related issue but rather a function of how Roon handles metadata processing. As such, there are no immediate troubleshooting steps we can offer, so we’ll be moving this thread over to our Feedback category for now.
We appreciate your feedback and your continued engagement with Roon. Thanks again!
Hmm well 8 months to determine nothing. Well that’s the nail in the coffin for me, I don’t have a huge library or lots of unidentified albums. If this is expected behaviour for a premier app then I am not paying for it any longer as it’s not fit for purpose.
There you have it; at good last an admission that the miserable performance during those backend processes is how it is designed and implemented… I guess Roon just isn’t for us…
Good that there are alternatives…
While you may technically be correct with your statement, doesn’t the number complaints and details provided suggest this is a support issue that Roon should have been much quicker to engage with. It’s seriously impacting the use of Roon by your customers.
Moving it to a feedback thread that’s barely commented on by Roon staff is in effect hiding the problem.
It disappointing that it’s taken this long for so little to happen.
It’s fine if the server does metadata update work when it’s idle or has spare time, obviously.
However, when there is an interactive user who is browsing, editing, playing music, or whatever, then the server just as obviously should prioritize the interactive work.
If the hardware is appropriate for the library size, but the user gets an unresponsive system just, for instance, because they made a few edits, and the server then immediately seems to prioritize metadata updates, then it’s hard to not classify this as a bug. If the code works as designed, then the bug is IMHO in the design.
I have just a 50k tracks library on reasonable hardware (ROCK 10i5), just 83 unidentified albums, no crazy amounts of child folders or tracks in a folder, and rather small numbers of tags. It is not a big problem for me that severely hurts my general enjoyment of Roon, but if I make a few metadata updates it’s also better if I pour myself a coffee until the server has settled down again a few minutes later. It can be quite annoying if you just sit down to do some editing work because you found a time slot to do it. And as far as I can remember, this seems to have become a more prominent behavior over time.
I’m a little disappointed by this response @benjamin
I sense these words have come down from the branches above in the Roon tree.
During my endeavours to give you guys nor I for on my Qobuz related support thread, the once deleted albums came flooding back in batches of up to 600 tracks at a time, hammering a single CPU core for the duration. I was watching the progress at one point on my iPad and then the Roon Remote app crashed. I also noticed a real sluggish affect on performance on my iPhone Roon Remote.
These were Qobuz albums and I’m getting hit with system debilitating normal operating processes. Give over man.
The metadata updates should be background user controllable. Not during use.
Well, as much as it pains me and my bank balance for the wasted lifetime subscription (I knew the risk), I have uninstalled Roon.
I know you support and dev guys are under pressure to deliver new features etc, but stability and performance is a fundamental aspect of your jobs.
Plex Media Sever allows me when to have my library rescanned. Other options allow the user to do manual refreshes.
Oh well. Music still plays in my house, just by different means.
Yes this really has gotten much worse in the last couple of years.
And nicely put as most of the time it is a slow down in user interface which can be annoying but not the end of the world, other times it makes Roon unusable, often for no apparent reason to the user.
Some have suggested metadata update Windows as Plex and other apps have and I have that set up in Plex to only do it’s scanning and updates between 3:00 AM and 6 AM. Music doesn’t show up right away and the heavy duty Sonic analysis runs without impacting the rest of the system.
I installed Roon 1.8 the other day
I import my whole library of 55k tracks in less time than 2.0 does. 1.8 spreads the love evenly across all 6 of my cores. I was watching via htop. It maintained a warm temp without spiking like 2.0 does.
I then added my equally sized Qobuz library and again in less time was done. Roon performed well enough during all this I could play music and have full control without too much sluggishness.
@benjamin - if this is inherent to Roon’s functioning, wouldn’t it be better to allow users to set a specified time to update metadata. I can safely say that I never listen to music at 4 am in the morning, so that would work for me. I can’t, for the life of me, work out why this isn’t offered as a solution.