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.
6 Likes
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…
4 Likes
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.
5 Likes
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.
7 Likes
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.
2 Likes
@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.
4 Likes
I think you are right, this is actually a development related issue. Call it a bug, a malfunction, or just really bad architecture. But nice that Roon admits it’s there.
Then let’s have the developers fix this “expected behavior” or allow user control over it. Effectively what you are saying is that you know Roon malfunctions but it’s something one just has to live with.
Roon: please don’t be deluded to believe this is people running large libraries on under spec gear. My dedicated Ubuntu server is a 6-core 3.9 Ghz with burst speed up to 4.7 Ghz. PCIE 4.0 M2 drive. Other than a threadripper it was about the fastest thing I could buy when I was building it.
There is no need for Roon to act as it does. This is bad programming. If Roon is burdened with too much technical debt to fix it, then create a workaround. Set a time for metadata updates and let users designate unidentifiable files as to be skipped on metadata searches.
4 Likes
When a feature has a noticeably negative impact on the user experience, then it’s typically considered a defect. The only case in which it’s not a defect is when it the software’s non-functional requirements do not include things like Availability, Operability, Robustness, Usability.
I don’t suspect that Roon has eschewed those deliberately, has it?
I don’t have this problem with my setup, but it doesn’t make it any less real for those who do. Would Roon like to look closely at my setup to see what is causing it to behave so well (other than ARC, which is getting better but still not quite there yet)?
4 Likes
So that folks know this is there, I’ve already submitted a feature request to have this expected behavior remedied:
We need votes, and lots of them. There are lots of different posts and threads that I believe are about this same general issue. All those folks need to be made aware…
2 Likes
James I think we have all voted for this request.
If only we could get Roon staff interested in the same we might make some progress 
1 Like
I wonder why we as users and customers of Roonlabs should feel the need to get the attention of Roon management and developers in the first place. The product is what they decide to design and implement, in the order of priority which they decide upon, and which to us is largely opaque. As committed users our collective brains are being picked as to suggestions for new features or improvements, but we very rarely get any feedback, and certainly have no influence at all on what is finally put on the roadmap. It’s their responsibility to make progress, and we only decide if the progress made is significant to us or not.
Roonlabs leans on committed forum users to do substantial user support work, and now more recently even beta testing work. But that doesn’t in turn mean that we as users might lean on Roon to prioritize work on what we feel are important defects, bugs and shortcomings of the system. Doesn’t work like that. We have only the power of our purse. And that’s why I have decided to not renew my subscription which comes up in April, and several months ago switched to an alternative system. It works for me.
2 Likes