Please see https://community.roonlabs.com/t/grouping-error-again/296523.
Essentially, as that thread details, I have a box set which Roon can't find. The exact same box set isn't in MusicBrainz or Discogs either.
So I want to use my own title - especially for one particular track (CD 8, track 7), which is displaying incorrectly in Roon 2.48 build 1517 on macOS 15.4, as you can see from screenshots like this: https://community.roonlabs.com/t/grouping-error-again/296523/34?u=mark_sealey
But there appears to be a bug which prevents me from 'Preferring' my file's title as tagged (in Yate).
I can supply more screenshots, a more detailed "Steps to reproduce" etc and - if copyright allows (?) - send you the file which seems to be producing what looks like the bug in question.
Because track titles aren’t used for multi-part compositions – they use WORK and PART (file) tags instead. If you have them, “prefer file” for those, else disable their use to revert to use track titles (edit album at the bottom):
Your advice about WORK and PART is spot on, of course. I’m sorry that no screenshot I posted here made it clear that I have every last comma, quote, dash and full stop meticulously tagged with WORK and PART in Yate.
I want to see the movements of each quartet display with the correct title. There appears (I may be wrong; but if I am I can’t see how to ‘force’ it) to be a bug which prevents me from opting for ‘File’ rather then ‘Roon’.
Again: If you have the correct WORK and PART tags already, just instruct Roon to use them (and give up on showing screenshots pointing at track titles). Please post screenshots of your settings related to multi-part composition grouping instead and how Roon is not adhering to those settings.
In that case, with that setting - as I say in the discussion thread - everything displays perfectly; every single track including the Alternative finale of Opus 130.
And, as I say, when I prefer either ‘Roon’ or ‘File’ by selecting either of the first two options, not all the tracks - including this one one - appear correctly: with the correct Movement titles and as part of the correct Compositions. I take this to mean that Roon has not been able to identify the Box Set. I have tried forcing it to do so by supplying UPC and bar code.
There is a rogue movement, which only appears correctly, as you kindly point out that it might be expected to appear, when I Disable multi-part - as you suggest. Thanks again for the advice. I wish some of it were behaving - in this specific instance (!) - as it’s supposed to do And as it has always done for me with Roon… until this one Box Set.
@BlackJack - @Mark_Sealey has every reason to expect that he should be able to enable multi-part compositions for his de-identified album and that Roon should use the WORK and PART tags he has populated. What is baffling is that it appears that some information from the album when it was previously identified (before he de-identified it) seems “stuck” and overrides his WORK and PART tags when the album is de-identified. That is what he is showing in the below. There is no good reason Roon should be showing Op. 135 for track 8-7, except for possibly oddly cached data from when the album was identified with bad data to begin with.
@Mark_Sealey I might suggest that what you are asking Roon to look into more specifically is this:
Is there a way that you can clear out the information that seems to remain from the original album identification process — esp. now that the album has been de-identified – that led to this track being “stuck” as Op. 135 even when using all of your own metadata?
I have (amongst other troubleshooting experiments):
deleted the entire box set several times from within Roon, restarted the Server in the web interface, then Cleaned up the library
forced rescans
in the Album Editor > Album Options re-identified the album
in the Album Editor > Album Options tried to Fix track grouping
in the Album Editor > Album Options Rescanned the album
in the Album Editor > Metadata Preferences > for 1 album > Set preference to ‘Prefer File’; and toggled it on and off to try and make it stick
in the Album Editor > Metadata Preferences > for the tracks of 1 album > Set preference to ‘Prefer File’; and toggled it on and off to try and make it stick
renamed the file at the filesystem (then of course repeated steps 1, 2
making changes (including toggling to force a re-read) of the tags for the errant file in Yate
repeated the appropriate steps above for the file itself:
Another way of putting the question, I think, would be: Where does Roon get its titles from in the of the three settings for MULTI-PART COMPOSITION GROUPING; and so why is it only getting one (Disabled) correct?
The conclusion I’m tempted (though will not ‘push’) to reach is that there are errors in the algorithms for ‘unidentifiable’ box sets and that to overcome gaps Roon ‘fills in’ with its best guess - only when grouping.
I’d like to repeat, I’m a happy Roon lifer; this is not a criticism
Indeed. If there is a way to do that in addition to and/or in tandem with complete deletion, re-identification, Library cleanup and parallel steps, it’d be very useful when someone from @Tech_Admin (?) reads this to explain what is necessary.
Thanks for the report and for the copious amounts of screenshots. I do wonder how this album would look on our end to see if we can reproduce the issue, would you be able to send it in for analysis?
Thank you again for bringing this issue to our attention. We’ll attempt to reproduce this in-house and confirm whether there’s a deviation from the expected treatment in this case. We’ll let you know what we determine. Should this require a fix or specific workaround, we’ll let you know. Thanks!
Appreciating that this may seem quite complicated, I’m happy to supply any and all details you might need in getting to the bottom of it .
Just want to emphasize: not a complaint; hoping it will also help other users who need to get (apparently?) unidentifiable box sets as close to accurate as poss.
No updates yet, but our team still has a ticket for further review - we don’t need any additional details at this time, but thank you for your offer and continuous clarity when posting here on the community! We’ll follow up as soon as we have more information to share.
We’re likely going to need a copy of your database to reproduce this internally, as performance/composition munging is performed locally and not in the cloud.
At your convenience, please navigate to your RoonServer’s Database Location, compress (.zip) the entire “RoonServer” folder, and upload it here to our secure database uploader: DB uploader. Thank you!
Thank you for your help! We’re going to take a deeper look at the treatment of custom track title vs. metadata work field under these conditions, among other variables. Once we’ve clarified the expected behavior we’ll respond with next steps.
.
And as it has always done for me with Roon… until this one Box Set.
