[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.

[LukeWinikates]

With the new protobuf format, is there a path forward for Shairplay Sync to support it if someone is able to comprehensively reverse engineer it?

[mikebrady]

Potentially, but be warned -- it's a bit of a monster. I've had a brief look at it. The first thing is that it's only known for Apple devices such as the Home Pod. Non-Apple devices seem to get a different protocol. So I haven't made any great headway on it. But maybe fresh eyes...

[b3ll]

Found an interesting development: https://github.com/antimof/UxPlay appears to have a correct implementation that receives a DACP-ID and Active-Remote in the headers for /info.

I don't know what's different, still trying to see what's up there. Maybe the features supplied?

[b3ll]

Ah, it appears to be tied to the AirTunes version. shairport-sync uses 366.0, however supplying 220.68 causes DACP-ID and Active-Remote to be correctly sent down. However it fails to connect with Unable to connect to "device name" on my iPhone.

Altering UxPlay to report 366.0 causes it to no longer receive any Active-Remote or DACP-ID. Part of me wants to think iOS has a fallback hardcoded for < 366.0 to support legacy Apple TV devices (which is what UxPlay is spoofing)… so maybe there's something there.

[mikebrady]

Many thanks for this detective work! When I get a chance, I'll play around with it a bit.