FAQ: What options does Strawberry have (implemented or otherwise) for [mobile] remote controls?

[SneakyWhoami]

This was going to be a simple question, and the gist of it is in the TLDR, but I wrote an essay to go with it.
For basic use, KDE Connect is hard to look past.

Personal:
Today is my first day running Strawberry, and it fixes all of my most painful papercuts and wishes (lyrics, libre.fm...) but since leaving Amarok I had developed this habit of using music players as whole-house arrangements controlled AFK.

TLDR / Bullet Points / Executive Summary:

0. Strawberry is as fresh as possible
1. Strawberry doesn't have a specific "Mobile Device Remote Control" thing at the moment because there's nobody available to maintain that
2. People ask about point 1 very often (and the questions are taken very seriously, I see)
3. How much support could a third party give it (patches, man hours, idk), to bring back such a tool?
4. Are there any sensible alternatives usable right now? (preferably metadata-aware) Even local is OK

Background:

• Clementine has a network remote, but It's extra work to maintain, and Strawberry aint Clementine any more!
• Mentioned in (Feature Request) Strawberry for Android and iOS #678
• In Integration of ClemRemote ? #595 (a short while ago at the time of writing), is a description of the remote situation and what looks like onboarding @mbruel, who he has a nice looking remote (I haven't tried it) at https://github.com/mbruel/ClementineRemote
• In Network remote #261 some alternative approaches are discussed, including something called "anyremote" (sf.net) - not mediaplayer-specific, but maybe useful. Also mentioned there is KDE Connect, which is perfectly adequate for seeing/changing/pausing the currently playing song (and pauses when you get a phone call, IIRC, so it's worth having this in any event). It also hints at using QDbus directly, which would provide a mostly complete interface (but doesn't look able to manage metadata yet, eg rate songs?)
• Remuco is available for Android, and available in some (retired) linux software repositories. How it works is, it runs as a script on the computer, and that script communicates (via MPRIS/Dbus? DCOP? Whatever's available?) with the media player to control it - although in some cases the players have a scripting interface and it runs in there. The Remuco script has its own network protocol with which the android app communicates. It is, however, a retired project with a (great) totally un-specialized java client.
• Ubuntu 16 had a CLI package called "mpris-remote", which can't do what I personally want, but would do all the basics because MPRIS

Reformulating the thing to fit the background:

• Does Clemremote have a good prognosis for Strawberry? It's Qt-based and it's really pretty.
• If not, would a (... re-skinned ..?) clementine remote be a doable approach if someone dedicated themselves to that? Strawberry is in places totally different to Clementine, so I guess this might be a little bit more involved than "reverse this patch". What kind of time commitment would this involve?
• What's the coolest thing available other than a dedicated remote? These suggestions from Arch Wiki seem like enough for a third party to knock something together for basic needs (web page for their mobile on the LAN? home assistant integration?) Personally, though it doesn't do all I want, KDE Connect is the first thing I reached for.

I figured this was good to throw at the new "Discussions" thing because it's not really a bug, or at least not really Strawberry's bug. And I might be able to help, depending which way things are supposed to go. So I'm interested in the parameters

[jonaski]

Hi.
I looked into it a while back, but I realize it's just going to be additional work for something I'm not very interested in.
The main issue now is that we lack contributors. This project has been on GitHub for over 3 years, and there are only a few contributions from others than me to this project. No other contributors in the past 1/2 year.
Of course I didn't expect hundred of contributors, but at least that there would be 1 or 2 more regular contributors that I could trust to give push access by now, but there aren't any.
In beginning there were several developers who said that they would participate, but none of them contributed anything. I've exchanged e-mails with several others and given coding advice, but it has not materialized in anything.
When adding something new, someone needs to deal with reviewing incoming PR's, fixing bugs, dealing with issues from users, etc.
A common thing I see on GitHub, and what I see in other projects too, a lot of developers are just opening issues for whatever they want there and then, instead of participating. If they are willing to participate it's usually just to throw in some additional feature without having to deal with it later. Very few are committed to helping reviewing PR's or helping with issues from users.

[mbruel]

Hi,
Well I had some time when I proposed to do it but then we didn't find the good spot...

I guess I could port Clementine remote server code to Strawberry and maintain it but as I don't have neither too much time for it nor any personal interest, I would do it as a minimal port meaning keeping Clementine protocol buffer specification.
There are several reason and advantages:

1. ClemRemote (on desktop, Android, iOS) would work for both Clementine and Strawberry (no need to have 2 baselines for me to maintain)
2. The server code for the remote is kind of on its own, not really impacting so much the code of the Media Player itself.
3. Evolution on Clementine's server code will be easier to port in Strawberry too (that's why forks are interesting)

I'm willing to maintain that part and correct any issues raised on that area and that area only.

[poldi171254]

I've had a look at the closed posts in relation to this and it's obviously been a while since the developers of both Strawberry and the ClemRenote had a conversation about this.

I'd like to work on the Strawberry side of this if somebody can have a look at the Android side of this.

[dallasspohn]

Are there any APIs so we can write our own controls then?

[jonaski]

There is only D-Bus

[buckmelanoma]

KDE Connect can be used for this purpose and is cross-platform. I've used it with Strawberry and it works great.

[dallasspohn]

Same. Also, VNC if you can not use KDE connect.

To interact with Strawberry via D-Bus, you'll need to use a D-Bus client library or tool in your preferred programming language. For example, you can use dbus-send on the command line to send D-Bus messages, or use libraries like dbus-python for Python or dbus-java for Java.

Here's an example of how you can control Strawberry using dbus-send on the command line:

Play music

dbus-send --print-reply --dest=org.strawberrymusicplayer.Strawberry /org/strawberrymusicplayer/Strawberry org.freedesktop.MediaPlayer2.Play

Pause music

dbus-send --print-reply --dest=org.strawberrymusicplayer.Strawberry /org/strawberrymusicplayer/Strawberry org.freedesktop.MediaPlayer2.Pause

Stop music

dbus-send --print-reply --dest=org.strawberrymusicplayer.Strawberry /org/strawberrymusicplayer/Strawberry org.freedesktop.MediaPlayer2.Stop
You can explore additional D-Bus methods exposed by Strawberry's D-Bus interface to perform more advanced actions. Refer to the Strawberry documentation or introspect the D-Bus interface to discover available methods and properties.