FEATURE: Implement rest of MPRIS2

[xxxserxxx]

The current implementation is a partial hack. This ticket is to track:

• Implementing the remaining "required" MPRIS2 functions
• Changes to ensure dbus paths are being set properly
• Ensure dbus properties & functions are correct (follow the MPRIS2 spec)
• Support the MediaPlayer2 dbus functions. Currently only Player functions are implemented, which means clients can't, e.g., Quit

For example, the stmp code currently supports client-triggered volume, play state, and "next song" changes, and that's about all. It would more usefully update the current song metadata, and update the position property. In any case, it should support the minimum "mandatory" MPRIS2 functions/properties.

[dweymouth]

Is there any chance you'd consider implementing this as a MPRIS player Go module in its own repo, to allow reuse in other projects? I'm working on a Subsonic client also written in Go (mine is a GUI client) and I plan to support MPRIS as well. I think it could be to the benefit of both projects to share common code so that any fixes and improvements can automatically land into each client.

[xxxserxxx]

Hi @dweymouth! I would happily collaborate on an MPRIS library! I couldn't find one for Go, or I'd have not written my own code. The mpris part isn't bad, but the dbus integration is giving me headaches.

Anyway, I'll pull it out separately. I only use github for submitting patches to other people's work; I'll probably put the MPRIS library in Sourcehut.

[dweymouth]

Sounds great! What I think it would need is a way for the client to set its name (e.g. stmp or Supersonic), APIs to set the now playing info and play queue, including cover art, and either allow the client to set callbacks to be notified when the application has been requested to pause, play, seek, next, etc., or else have a channel(s) where these commands are sent on, I don't really care which.

[xxxserxxx]

The MPRIS support is super basic right now; very few of the commands are implemented. Once I pull it out, patch contributions will be the fastest way to get full coverage.

[dweymouth]

Cool, drop the link here once you've got a repo up and running and I'll help contribute coverage for features I want to use

[xxxserxxx]

Have you looked at other mpris implementations? It doesn't show up early in github searches, but I found Pauloo27's because of their Polybar controller, and it looks pretty mature. I'm going to first see if I can replace my hacked implementation with theirs, before I create another separate library.

[dweymouth]

I did see that one I think, but as far as I can tell it looks like it's strictly the client-side library i.e if you were to write playerctrl in Go you could use it but not as a music player to respond to the requests and export the now playing info. Of course it could be forked to add the player-side API as well.

[xxxserxxx]

Oh, yes... I think you're right. That was the main issue I had: they were all client-side libraries, and this one looks the same. Ok, back to the original plan.

[xxxserxxx]

https://git.sr.ht/~ser/gompris

533 lines of untested, unfinished, and probably not close to working. But there it is. I think the whole MPRIS2 spec is covered by the API, at least.

[dweymouth]

Nice! I will look into working this into my app soon-ish. I have some other higher priority features I'm implementing first. I also hope to implement interfacing with Mac OS's MPNowPlayingInfoCenter APIs along with MPRIS, so we'll see how that goes. If it works well I can split out that into its own go module so stmp could use it as well.

[xxxserxxx]

I wouldn't: it's completely untested, and probably doesn't work. I haven't tried replacing the code in stmp yet; the library is nowhere near ready.

I also have some other priorities to work on, but the library needs, at a minimum, unit tests and a (dummy) test server added to see how it plays with clients like playerctl.

I shared it only in case someone was interested in hacking on the framework. It's not yet ready for use.