[Problem]: dbus Commands Ignored on iOS 17.4 and macOS 14.4

[b3ll]

What happened?

For some reason the update to iOS 17.4 broke support for dbus commands. If I'm using Apple Music on my Mac and airplaying to shairport-sync and I play or pause via dbus it works fine (I was using the shairport-sync-dbus-test-client).

However, if I do the same thing with my iOS device (iPhone 15 Pro Max) airplaying to shairport-sync, the dbus commands are ignored. This was working a few weeks ago, so maybe something changed with 17.4?

I'm not too familiar with the airplay spec / how remote commands are done (or how the commands were even reverse engineered). I'm actively trying to read the shairport-sync source, but if you have any ideas that'd be super helpful!

Relevant log output

iOS 17.3.1:

Listening on the D-Bus system bus.
Starting test...
Using the RemoteControl interface, play for five seconds, pause for five seconds and then resume play...
Play...
Pause...
 *** Properties Changed:
      ShairportSync.RemoteControl.PlayerState -> 'Paused'
Play...
 *** Properties Changed:
      ShairportSync.RemoteControl.PlayerState -> 'Playing'
 *** Properties Changed:
      ShairportSync.RemoteControl.ProgressString -> '2811325406/2812436593/2823525318'
 *** Properties Changed:
      ShairportSync.RemoteControl.ProgressString -> '2811325406/2812437994/2823525318'
Using the RemoteControl interface, set AirPlay Volume (range -30 to 0) to -30, -20, -10, 0 and -15 for five seconds each...
Set AirPlay Volume (range -30 to 0) to -30
 *** Properties Changed:
      ShairportSync.Volume -> -144.0
 *** Properties Changed:
      ShairportSync.RemoteControl.ProgressString -> '2811358305/2812686132/2823558217'

iOS 17.4:

Listening on the D-Bus system bus.
Starting test...
Using the RemoteControl interface, play for five seconds, pause for five seconds and then resume play...
Play...
Pause...
Play...
Using the RemoteControl interface, set AirPlay Volume (range -30 to 0) to -30, -20, -10, 0 and -15 for five seconds each...
Set AirPlay Volume (range -30 to 0) to -30

System Information.

Raspberry Pi 4B

Linux raspberrypi 6.1.0-rpi7-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm

Configuration Information.

From "uname -a":
 Linux raspberrypi 6.1.0-rpi7-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux

From /etc/os-release:
 Debian GNU/Linux 12 (bookworm)

From /sys/firmware/devicetree/base/model:
 Raspberry Pi 4 Model B Rev 1.5

Shairport Sync Version String:
 4.3.3-dev-6-ge36ec5c4-AirPlay2-smi10-OpenSSL-Avahi-ALSA-soxr-metadata-dbus-sysconfdir:/etc

Command Line:
 shairport-sync --displayConfig

Configuration File:
 /etc/shairport-sync.conf

Configuration File Settings:
 general :
 {
   ignore_volume_control = "yes";
 };
 alsa :
 {
   output_device = "hw:USB";
 };
 pw :
 {
 };
 metadata :
 {
   enabled = "yes";
   include_cover_art = "yes";
   cover_art_cache_directory = "/tmp/shairport-sync/.cache/coverart";
   pipe_name = "/tmp/shairport-sync-metadata";
 };

PulseAudio or PipeWire installed?

• Check if your system uses a Sound Server.

How did you install Shairport Sync?

Built from source

Check previous issues

• Confirm

[b3ll]

Just updated my MacBook to Sonoma 14.4 (from 14.3.1) and now dbus no longer works there either -_-

So yeah, looks like 17.4 and related releases either ignore or changed their means of handling remote commands ¯\_(ツ)_/¯

[mikebrady]

Thanks for the report. Darn it, but I think you're right 😕.

[b3ll]

Some more info: it appears as though the commands still work fine with AirPlay 1. I rebuilt shairport sync without AirPlay 2 support and it works as expected (both with 17.4 and 14.4)

I guess on the iOS side it's selectively handling them? Or the commands changed? I'm trying to find what libraries or processes handle the commands atm

[mikebrady]

Thanks. It seems that in AirPlay 2 mode, an important parameter -- the DACP ID -- is not being sent by the player (e.g. iOS) in the same way as in AirPlay 1 mode. That certainly would cause problems. Unfortunately we have no specifications, so we don't know where the DACP ID might be found now, if anywhere. Some sleuthing is needed, I think!

[b3ll]

Oh, that makes sense. So maybe the commands still work, but there's just no ID to send to.

Still looking to see if I can find what even generates that ID / handles all this

[mikebrady]

Thanks. Another parameter, the "Active-Remote" information, is also missing. 😕

[b3ll]

Had a few stabs of it and I can't find anything. Maybe it's a bug? Maybe it's gone

Even inspecting requests doesn't show anything… it's possible it all got folded into MRP (https://pyatv.dev/documentation/protocols/#media-remote-protocol-mrp)

It also appears controls within the Sonos app are now broken (with my iPhone streaming to a Sonos device) so I have no idea what's going on

¯\_(ツ)_/¯

[TB31388]

Has a fix for this been found?

[mikebrady]

Unfortunately, no fix has been found -- it seems to be a permanent change at Apple's end...

[LukeWinikates]

Just found this issue after spending some time trying to debug play/pause from the web ui of my hifiberry device.

I'm curious - as a fallback, would it be feasible to change the CanPause mpris response to false if the stream was initiated by a newer iOS device version, and implement a fallback Stop that stops playback even if it can't successfully send the message to the initiating airplay device?

I know that's very inelegant, but I want to be able to force playback to stop without having to find the initiating device.

I haven't looked closely at the link @b3ll provided about the mrp protocol. Based on the discussion here, is it reasonable to speculate that Apple is moving away from the protocol shairport-sync has been using and moving to the mrp protobuf-based format?

[mikebrady]

Thanks @LukeWinikates -- that's not a bad idea; let me think about it, please.

Yeah, I do think Apple might be dropping support for that old protocol, which makes sense for them but sadly not for us.