Prefer AlbumArtist to Artist for sorting/display/everything.

[sleepdeprecation]

Using AlbumArtist instead of Artist means that sorting is done better. There are things like compilation albums, or collaborations on songs which puts the collaborators in the Artist field, but uses the AlbumArtist field to store the album's artist.

There are two options I see to make this work:

1. On startup, find all songs without an AlbumArtist and copy their Artist field to the AlbumArtist field. Longer startup time.
2. When getting all artists, return all AlbumArtists, and Artist fields if a song doesn't have an AlbumArtist. When getting all songs by an artist, grab all songs by AlbumArtist and Artist and merge the lists. Longer retrieval time in application.

[mpeterson2]

With option 1, we either have to store the AlbumArtist/Album field by editing the files (which I wouldn't want something editing my files without me knowing), or we would have to do it on every startup and keep the info in memory. We'd also have to manually update our list of artists, while we currently get it from MPD on demand, so if an artist is added, we let MPD handle it. I think this could add some complexity, and be memory/start up time inefficient.

Option 2 on the other hand may add a few milliseconds to every artist request, but no one will notice that. It also doesn't seem like it will add too much complexity (I think).

Currently, when we grab all artists, we use the command list artist. This just returns a list of artists. We could also use list albumartist, and merge the lists together. We'd have to ignore duplicate Strings, but I don't think that would be that hard. I don't see any Set data type for Go, but there are a few solutions.

1. We could check for duplicates every time we add an artist. This seems like it could become time consuming with a large library.
2. We could use a HashMap. The key and the value would both be the Artist/AlbumArtist. When we're done creating the HashMap. Next we have two options.
   1. Send it to the frontend as a Map and have the frontend deal with it. This kinda sucks because we're sending so much extra data.
   2. Convert it to the list and send that to the frontend. This would be the way that I would go with option 2. It wouldn't change the frontend at all and we aren't sending any extra data over the internets.
3. We could just send everything over to the frontend, where Dart does have a Set and we could deal with it there. This isn't too ideal because we're sending/receiving more data than we need to.

Option 2ii sounds the most network efficient to me, but option 3 sounds the easiest. Any thoughts on this?

[sleepdeprecation]

I though MPD would have a way to play with the database without fiddling with the files. It doesn't.

Isn't a Set just a list? Which in Go is an array or slice. But still, we'd need to do it manually when we get down to the song level. I don't know why we'd need a map...

---

What seems best to me is to basically create our own DB layer over MPD's:

1. At startup, get all songs, add them to our DB. We can, and should, save this DB somewhere to make startup costs smaller in the long run.
   1. When adding files to our DB, fill in the AlbumArtist field with the Artist field if it's missing.
2. Make our DB layer basically the same as MPD's DB querying interface.

---

What seems even better to me is to mark this as wontfix because we're basically going to be creating our own DB layer over MPD's which is unnecessary and we can just tell the users (AKA me in this instance) that they're wrong and this is the way to do things.

[mpeterson2]

In Dart, a Set is a list that doesn't contain duplicates.

I think I agree with the wontfix part. Mostly because I don't like my songs sorted by AlbumArtist, and I always just make sure the AlbumArtist field is the same as the Artist field.

[sleepdeprecation]

wontfix.