Is there an ETA for this?
It’s being worked on right now, and it’s our #2 priority (behind iOS support).
I generally don’t name dates until features go into alpha testing–before then, there’s always the possibility that priorities will shift around or delays will occur.
There’s a few weeks of effort here–unlike some of the other changes we’ve released in the audio area, pretty much everyone on the team ends up touching part of this one, there’s a substantial amount of UI to be designed and built, and a lot of testing/QA is required since anytime we muck around in the data modeling stuff, there’s a risk of regressions, corruption, data loss.
Album-title, track-title, Album-Artist, Artist, Composer, Album art
Yes
disc#, track#,
These are already solely determined by local data (munged from file names, directory names for certain multi-disc set organization schemes, and file tags). I don’t think anything is changing here other than perhaps making them editable manually in the UI.
Genre field
I think genre is going to be handled differently.
We will probably keep local genres and Roon’s genres separate in the data model (insofar as representing how they attach to albums and artists), but let them live in the same hierarchy with Roon’s genres, and make that hierarchy user editable.
We are planning to make genres of both types editable (add/remove from album/artist), so personally offensive cases can be fixed as one-offs. We may make settings for hiding/showing local genres or Roon’s genres for people who prefer to see only one or the other as a higher-level choice.
If you are not a groomer, your genre tags are probably a mess. I mined a bunch of un-groomed files and looked…it’s really gross what’s actually in that tag field in real life, and we don’t necessarily want to pollute the app with that mess by default.
This is still in flux, and we plan to solve the problem. It just requires a more complicated solution than the other fields.