-
-
Notifications
You must be signed in to change notification settings - Fork 572
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Problem]: dbus Commands Ignored on iOS 17.4 and macOS 14.4 #1822
Comments
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 ¯\_(ツ)_/¯ |
Thanks for the report. Darn it, but I think you're right 😕. |
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 |
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! |
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 |
Thanks. Another parameter, the "Active-Remote" information, is also missing. 😕 |
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 ¯\_(ツ)_/¯ |
Has a fix for this been found? |
Unfortunately, no fix has been found -- it seems to be a permanent change at Apple's end... |
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 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 |
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. |
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? |
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... |
Found an interesting development: https://github.com/antimof/UxPlay appears to have a correct implementation that receives a I don't know what's different, still trying to see what's up there. Maybe the features supplied? |
Ah, it appears to be tied to the AirTunes version. shairport-sync uses Altering UxPlay to report |
Many thanks for this detective work! When I get a chance, I'll play around with it a bit. |
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 ? |
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. |
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. |
I don't believe anything is lost per-say, however switching to I don't think that would be trivial to support / implement |
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:
iOS 17.4:
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.
PulseAudio or PipeWire installed?
How did you install Shairport Sync?
Built from source
Check previous issues
The text was updated successfully, but these errors were encountered: