Implement latest MPD protocol v0.22

[BrainStone]

The current protocol version of MPD is 0.22. And as many clients have implemented it already, they hardly can use mopidy at all. Anything that's beyond basic commands like play/pause, skipping forwards and backwards, volume control and replayer/shuffle/consume status is not working due to the big differences in the protocols.
Important stuff like retrieving the track list, albums, searching, etc.

It would be very nice if mopidy could get its long overdue protocol update (I mean even 0.19 is only partially implemented since at least October 2015 (almost 4 years without a protocol update), accoding to #2)

[kingosticks]

Last time I checked it was our complete lack of support for group_by that was causing the most friction. That would be the place to start, particularly before Mopidy v3.0 if support requires API changes.

[tobast]

I've recently tried to setup a mopidy server, but the lack of group_by basically makes all mobile MPD clients (mpdroid and MALP) unable to load the library.

I'd be willing to take the issue, but it seems to me that this would require a breaking change in the plugin library interface of Mopidy.

Alternatively, I feel that the LibraryController.search could reasonably used when there is at least a group_by term. I haven't dug into all the library plugins, but it seems reasonable to me to assume that this would not be so inefficient.

Should I try to implement this?

[BrainStone]

Considering this project is looking for a maintainer, I doubt there's anyone to ask for a direction of the project. So just go for it.

[tobast]

I was considering that, but I would also find it sad to implement this and have it sitting around as an unmerged PR.

This would also be a significant change, since this would mark the LibraryController.get_distinct API as on its way to deprecation if I trust the docs – it apparently mostly serves the purpose of the MPD integration. Maybe @jodal's insight is needed on this?

[kingosticks]

If we don't need get_distinct anymore or if it changes, or you need something new or whatever, we can do that. That's not a problem, it just takes time to propagate that sort of thing through the ecosystem. PRs bringing this frontend back to life would get the review they deserve, rest assured. But we can only merge what works, in terms of functionality and also maintainability. Not everything we've had submitted has met that criteria and sometimes they never get there, despite efforts.

[tobast]

Then I'll try to get this done soon! Thanks for your reply. And I certainly understand that you need to keep the project sound and maintainable, no worries there :)

[AndydeCleyre]

I don't know if this is the best place to discuss goals for MPD protocol version support . . . but it might be.

So I want to add:

• multiple tools in the ecosystem will fail altogether with mopidy-mpd, due to the lack of support for the binarylimit query, which was added in MPD 0.22.4 (2021)
• mpdris2-rs is one such tool, but I don't know its minimum-supported MPD protocol version aside from that, or what else it might choke on once binarylimit is implemented here
• rmpc is another, and lists a minimum MPD version for compatibility as 0.23.5 (also 2021)

Maybe others have more data points, but as rmpc is actively developed and quite popular according to its GitHub star count, I'm in favor of setting a goal here of supporting at least MPD protocol 0.23.5.

[jodal]

I don't want to promise anything, especially not timelines, but I'm personally quite interested in reviving mopidy-mpd and getting it up to date with the current MPD protocol. That said, I'm not going to touch this until I've wrapped up mopidy 4.0 and shipped that first.

Thanks for the pointers to modern MPD clients! It has been a long time since I've looked at clients, and when needing to confirm that mopidy-mpd wasn't more broken than before before a mopidy 4.0-related prerelease the other day, I had to resole to good old Sonata and ncmpcpp 😄