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

b3ll · 2024-03-08T05:57:14Z

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

The text was updated successfully, but these errors were encountered:

b3ll · 2024-03-08T06:23:51Z

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 · 2024-03-08T08:02:53Z

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

b3ll · 2024-03-08T09:38:15Z

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 · 2024-03-08T09:48:06Z

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 · 2024-03-08T09:59:37Z

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 · 2024-03-08T11:13:23Z

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

b3ll · 2024-03-09T05:57:36Z

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 · 2024-04-22T20:17:32Z

Has a fix for this been found?

mikebrady · 2024-04-28T13:51:59Z

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

LukeWinikates · 2024-06-01T19:38:31Z

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 · 2024-06-01T19:51:06Z

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 · 2024-06-01T20:38:53Z

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 · 2024-06-01T21:03:18Z

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 · 2024-06-11T04:44:50Z

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 · 2024-06-11T05:22:49Z

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 · 2024-06-11T07:55:39Z

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

thk4711 · 2024-08-02T12:35:09Z

Just a question. I have built a little streaming device with physical buttons an an infrared remote control. I used the dbus interface to send commands like play and stop. Since this is not working right now I would like to know if there is any other way to do this ?

mikebrady · 2024-08-02T15:45:01Z

Thanks for the post. Unfortunately, I don't know of any workaround for this. It seems to be due to the client programs not accepting these kinds of remote control commands any more -- it's not an issue with Shairport Sync.

jbardu · 2024-08-19T23:37:27Z

dumb question why can't we switch this to AirTunes/220.68 ?

mikebrady · 2024-08-20T00:06:08Z

dumb question why can't we switch this to AirTunes/220.68 ?

Thanks. What did you have in mind about this?

jbardu · 2024-08-20T03:22:06Z

dumb question why can't we switch this to AirTunes/220.68 ?

Thanks. What did you have in mind about this?

well I did warn it was a dumb question however if UxPlay works still with current IOS and remote control features like pause, skip etc, and it is using AirTunes/220.68 protocol, with DAC-P ID for the remote (it saves the code when it gets it), then what is lost between 330.x and 220.68 in terms of Airplay functionality ?

how different are they. I did some basic searching but as you know Airplay protocols are a black art and there is not really a definitive document on this.

b3ll · 2024-08-20T04:42:30Z

I don't believe anything is lost per-say, however switching to AirTunes/220.68 (or later) seemed to switch the stream to be AirPlay 2 but with NTP instead of PTP (at least during my testing, maybe this is AirPlay 1 compatibility mode). This isn't currently implemented or supported within shairport-sync and as such causes the connection to fail and never work (even if it does send down the DACP-ID / Active-Remote initially).

I don't think that would be trivial to support / implement

b3ll added the new issue label Mar 8, 2024

mikebrady added information and removed new issue labels Mar 8, 2024

mikebrady changed the title ~~[Problem]: dbus Commands Ignored on iOS 17.4~~ [Problem]: dbus Commands Ignored on iOS 17.4 and macOS 14.4 Mar 8, 2024

LukeWinikates mentioned this issue Jun 1, 2024

Pause Shairport-Sync from Beocreate UI hifiberry/hifiberry-os#554

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

b3ll commented Mar 8, 2024 •

edited

Loading

b3ll commented Mar 8, 2024 •

edited

Loading

mikebrady commented Mar 8, 2024 •

edited

Loading

b3ll commented Mar 8, 2024

mikebrady commented Mar 8, 2024 •

edited

Loading

b3ll commented Mar 8, 2024

mikebrady commented Mar 8, 2024

b3ll commented Mar 9, 2024 •

edited

Loading

TB31388 commented Apr 22, 2024

mikebrady commented Apr 28, 2024

LukeWinikates commented Jun 1, 2024

mikebrady commented Jun 1, 2024

LukeWinikates commented Jun 1, 2024

mikebrady commented Jun 1, 2024

b3ll commented Jun 11, 2024

b3ll commented Jun 11, 2024 •

edited

Loading

mikebrady commented Jun 11, 2024

thk4711 commented Aug 2, 2024

mikebrady commented Aug 2, 2024

jbardu commented Aug 19, 2024

mikebrady commented Aug 20, 2024

jbardu commented Aug 20, 2024 •

edited

Loading

b3ll commented Aug 20, 2024 •

edited

Loading

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

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

Comments

b3ll commented Mar 8, 2024 • edited Loading

What happened?

Relevant log output

System Information.

Configuration Information.

PulseAudio or PipeWire installed?

How did you install Shairport Sync?

Check previous issues

b3ll commented Mar 8, 2024 • edited Loading

mikebrady commented Mar 8, 2024 • edited Loading

b3ll commented Mar 8, 2024

mikebrady commented Mar 8, 2024 • edited Loading

b3ll commented Mar 8, 2024

mikebrady commented Mar 8, 2024

b3ll commented Mar 9, 2024 • edited Loading

TB31388 commented Apr 22, 2024

mikebrady commented Apr 28, 2024

LukeWinikates commented Jun 1, 2024

mikebrady commented Jun 1, 2024

LukeWinikates commented Jun 1, 2024

mikebrady commented Jun 1, 2024

b3ll commented Jun 11, 2024

b3ll commented Jun 11, 2024 • edited Loading

mikebrady commented Jun 11, 2024

thk4711 commented Aug 2, 2024

mikebrady commented Aug 2, 2024

jbardu commented Aug 19, 2024

mikebrady commented Aug 20, 2024

jbardu commented Aug 20, 2024 • edited Loading

b3ll commented Aug 20, 2024 • edited Loading

b3ll commented Mar 8, 2024 •

edited

Loading

b3ll commented Mar 8, 2024 •

edited

Loading

mikebrady commented Mar 8, 2024 •

edited

Loading

mikebrady commented Mar 8, 2024 •

edited

Loading

b3ll commented Mar 9, 2024 •

edited

Loading

b3ll commented Jun 11, 2024 •

edited

Loading

jbardu commented Aug 20, 2024 •

edited

Loading

b3ll commented Aug 20, 2024 •

edited

Loading