I noticed from the Changelog, that browse support for playlists and albums has been added for MPD clients.
Since I didn’t follow that closely, I wonder if there were any special reasons that browsing for artists, i.e. refs with type=Ref.ARTIST returned from an extension’s browse() method, was excluded.
Hello anybody?
If this is just an oversight, I can work on a PR allowing MPD clients to browse artist refs, too…
Don’t think there is any good reason this time either. Feel free to send us a PR to rectify this.
https://github.com/mopidy/mopidy/blob/develop/mopidy/mpd/dispatcher.py#L302 could probably even just be != Track
I like that idea (ref.type != Ref.TRACK) a lot!
Looking a bit more at the code I’m having some trouble deciding how this should work. Specifically I’m wondering about if we should browse “into” anything but directories. I.e. what should actually be expandable.
For HTTP clients all of this is up to the client to decide what is reasonable. While for the MPD frontend we are stuck making these choices for the clients. So any arguments for or against expanding things that are not being exposed as directories?
Note that backends could probably return a Ref.Directory(...) which has an artist URI, though I’m not sure we want to encourage this or not.
@jodal any thoughts?
Returning a Ref.directory(...) with an artist URI is exactly what Mopidy-Local-SQLite does now.
Advantages of being able to return a Ref.artist(...) would be limited to Web clients, like styling browse links differently, e.g. using artist/album icons or whatever. But this is already the case since Mopidy v0.19, when browsing album and playlist refs was introduced.
So to make this consistent, I’d suggest to either
browse(), it should also accept its URI as an argument for browse() (except for track URIs of course)or
@jodal, @adamcik: Any new thoughts about this? Need some encouraging feedback before I start working on a PR, even if it’s just a one-liner 
Lets keep it simple and just say everything that isn’t a track is browseable.