Pressing volume buttons on mobile have no effect on computer's volume

[niels0n]

Describe the bug

Controlling computer's volume through mobile's volume buttons is not working for GSconnect.
Opening the KDE Connect app on Android and going into Devices section, where the volume slides are, doesn't work with volume buttons. Manually moving the slides works, though.
Even trying to select a device from there doesn't work. Clicking on one of them just "ticks" them, but the tick is not exclusive, you can just tick them all with no effect (and to un-tick them I have to manually move the volume)

Steps to reproduce

1. Connect the computer with the mobile through GSConnect and KDE Connect.
2. Play something on computer.
3. On mobile, open KDE Connect app, go to Multimedia Control and then to Devices.
4. Try to control the volume using the mobile's buttons.

Expected behavior

The volume can be controlled with mobile's volume buttons, like on KDE.

GSConnect version

57

Installed from

OS package manager

GNOME Shell version

46

Linux distribution/release

Debian Sid

Paired device(s)

Moto G32

KDE Connect app version

1.32.2

Plugin(s)

No response

Support log

Screenshots

No response

Notes

No logs since they were totally useless, they were just about Fragments so nothing useful at all. Let me know if I can provide other useful informations please.

[ferdnyc]

OK, I see the commit in kdeconnect-android that added volume-key monitoring.

The difference between kdeconnect and GSConnect appears to be that when we send a sinkList to the device, we're not marking any of the sinks as enabled (which selects it as the default sink). Only when there's a sink marked as the default, will KDE Connect listen for volume key presses to change its volume.

(Tapping on the radio button next to a sink causes the app to send us an enabled: true message for that sink, after which it expects to receive a sinkList showing that same sink as being enabled. The fact that we're not doing so is why the radio buttons seem to function a bit strangely — they never receive the enabled sink status flags they're looking for, so they stay in a weird state until the next time we send a response that lacks enabled, at which point they reset.

Should be an easy fix, we just need to start tracking and including enabled values with each sinkList or sink update we send to the remote device. (The code already has the concept of a "current sink", but in our existing design it's simply whatever sink we last received a message for. We should be checking for an enabled value first, before blindly switching it every time we get a message.)

[niels0n]

Great! Let me know if I can help somehow.