Closed aaronk6 closed 6 months ago
LemmoTresto
commented
11 months ago I also get this issue, looks like it's trying to connect to it in the background to show it as one of the available speakers. Just like how the Apple TV and HomePods are visible with 'Control other Speakers & TVs'.
Edit: this also happens sometimes when nothing is playing.
mikebrady
commented
11 months ago Thanks for this post. Yes indeed, this is a new behaviour, and IMHO it is related to the new "Automatic AirPlay" feature of AirPlay -- please see this MacRumors piece.
aaronk6
commented
11 months ago That could be it. However, those messages keep appearing even when setting “Automatically AirPlay” to “Never” in Settings › General › AirPlay & Handoff. So it seems the handling in iOS 17 generally changed.
Is there anything I can do to help to fix this issue? I don’t have in-depth C knowledge and no understanding of the AirPlay protocol unfortunately, but if there is anything else I can do—such as narrowing it down further, testing certain specific combinations, etc.—I’m here.
mikebrady
commented
11 months ago Yeah, it’s puzzling alright. I don’t have an angle on how to deal with it at the moment, I’m afraid.
stevemurr
commented
10 months ago Hi,
I decided to look into this. On my network I have homepods, a denon and shairport-sync. I attached my phone to the computer ran rvictl -s <phone-uuid> to generate a network interface, then captured the phones traffic using wireshark. I compared the rtsp messages between the denon and shairport-sync. I focused on the difference between the feature hex:
Denon - TXT: ft=0x445F8A00,0x1C340
Shairport - TXT: features=0x405C4A00,0x1C340
Using this awesome documentation, I was able to compare the feature strings. It looks like the only difference was the HasUnifiedAdvertiserInfo bit is flipped on for Denon. When I flip the HasUnifiedAdvertiserInfo bit in shairport, I get this on client connection (using only -v the error message was No Content Plist).
0.000248847 "rtsp.c:1536" Responding with content of length 904
0.005944702 "rtsp.c:5252" Connection 2: Received an RTSP Packet of type "POST":
0.000019170 "rtsp.c:5254" Type: "X-Apple-AbsoluteTime", content: "722553128"
0.000005661 "rtsp.c:5254" Type: "X-Apple-HKP", content: "6"
0.000003643 "rtsp.c:5254" Type: "X-Apple-Client-Name", content: "iPhone 14 Pro Max"
0.000003492 "rtsp.c:5254" Type: "X-Apple-PD", content: "1"
0.000003165 "rtsp.c:5254" Type: "Content-Length", content: "37"
0.000003263 "rtsp.c:5254" Type: "Content-Type", content: "application/octet-stream"
0.000003328 "rtsp.c:5254" Type: "CSeq", content: "1"
0.000003477 "rtsp.c:5254" Type: "DACP-ID", content: "1B1221F9052E490A"
0.000003063 "rtsp.c:5254" Type: "Active-Remote", content: "2455355829"
0.000003613 "rtsp.c:5254" Type: "User-Agent", content: "AirPlay/750.13.1"
0.000003517 "rtsp.c:5254" No Content Plist. Content length: 37.
0.000005684 "rtsp.c:2205" Connection 2: pair-verify Content-Length 37
0.000520183 "rtsp.c:2241" pair-verify response
0.000011536 "rtsp.c:2241" Response Code: 200.
0.000003868 "rtsp.c:2241" Type: "CSeq", content: "1"
0.000003380 "rtsp.c:2241" Type: "Server", content: "AirTunes/366.0"
0.000003443 "rtsp.c:2241" Type: "Content-Type", content: "application/octet-stream"
0.000003543 "rtsp.c:2241" No Content Plist. Content length: 140.
0.000003321 "rtsp.c:5313" Connection 2: RTSP Response:
0.000003222 "rtsp.c:5314" Response Code: 200.
0.000003073 "rtsp.c:5314" Type: "CSeq", content: "1"
0.000003520 "rtsp.c:5314" Type: "Server", content: "AirTunes/366.0"
0.000003303 "rtsp.c:5314" Type: "Content-Type", content: "application/octet-stream"
0.000003538 "rtsp.c:5314" No Content Plist. Content length: 140.
0.000005134 "rtsp.c:1536" Responding with content of length 140
0.046515683 "rtsp.c:5252" Connection 2: Received an RTSP Packet of type "POST":
0.000034468 "rtsp.c:5254" Type: "X-Apple-AbsoluteTime", content: "722553128"
0.000005648 "rtsp.c:5254" Type: "X-Apple-HKP", content: "4"
0.000003906 "rtsp.c:5254" Type: "X-Apple-Client-Name", content: "iPhone 14 Pro Max"
0.000005144 "rtsp.c:5254" Type: "Content-Length", content: "9"
0.000010559 "rtsp.c:5254" Type: "Content-Type", content: "application/x-apple-binary-plist"
0.000008831 "rtsp.c:5254" Type: "CSeq", content: "2"
0.000006738 "rtsp.c:5254" Type: "DACP-ID", content: "1B1221F9052E490A"
0.000006415 "rtsp.c:5254" Type: "Active-Remote", content: "2455355829"
0.000006551 "rtsp.c:5254" Type: "User-Agent", content: "AirPlay/750.13.1"
0.000007912 "rtsp.c:5254" No Content Plist. Content length: 9.
0.000009065 "rtsp.c:2249" Connection 2: handle_pair-setup Content-Length 9
0.006672357 "rtsp.c:2287" pair-setup response
0.000007971 "rtsp.c:2287" Response Code: 200.
0.000001821 "rtsp.c:2287" Type: "CSeq", content: "2"
0.000007490 "rtsp.c:2287" Type: "Server", content: "AirTunes/366.0"
0.000001479 "rtsp.c:2287" Type: "Content-Type", content: "application/octet-stream"
0.000001684 "rtsp.c:2287" No Content Plist. Content length: 409.
0.000001723 "rtsp.c:5313" Connection 2: RTSP Response:
0.000001264 "rtsp.c:5314" Response Code: 200.
0.000001189 "rtsp.c:5314" Type: "CSeq", content: "2"
0.000001150 "rtsp.c:5314" Type: "Server", content: "AirTunes/366.0"
0.000001166 "rtsp.c:5314" Type: "Content-Type", content: "application/octet-stream"
0.000001263 "rtsp.c:5314" No Content Plist. Content length: 409.
0.000002362 "rtsp.c:1536" Responding with content of length 409
0.042485998 "rtsp.c:5252" Connection 2: Received an RTSP Packet of type "POST":
0.000033536 "rtsp.c:5254" Type: "X-Apple-AbsoluteTime", content: "722553128"
0.000005421 "rtsp.c:5254" Type: "X-Apple-HKP", content: "4"
0.000003878 "rtsp.c:5254" Type: "X-Apple-Client-Name", content: "iPhone 14 Pro Max"
0.000003459 "rtsp.c:5254" Type: "Content-Length", content: "457"
0.000003875 "rtsp.c:5254" Type: "Content-Type", content: "application/x-apple-binary-plist"
0.000003705 "rtsp.c:5254" Type: "CSeq", content: "3"
0.000003638 "rtsp.c:5254" Type: "DACP-ID", content: "1B1221F9052E490A"
0.000003698 "rtsp.c:5254" Type: "Active-Remote", content: "2455355829"
0.000003433 "rtsp.c:5254" Type: "User-Agent", content: "AirPlay/750.13.1"
0.000003928 "rtsp.c:5254" No Content Plist. Content length: 457.
0.000007056 "rtsp.c:2249" Connection 2: handle_pair-setup Content-Length 457
0.012046191 "rtsp.c:2287" pair-setup response
0.000013102 "rtsp.c:2287" Response Code: 200.
0.000003956 "rtsp.c:2287" Type: "CSeq", content: "3"
0.000003130 "rtsp.c:2287" Type: "Server", content: "AirTunes/366.0"
0.000003431 "rtsp.c:2287" Type: "Content-Type", content: "application/octet-stream"
0.000003743 "rtsp.c:2287" No Content Plist. Content length: 69.
0.000003476 "rtsp.c:5313" Connection 2: RTSP Response:
0.000003082 "rtsp.c:5314" Response Code: 200.
0.000004431 "rtsp.c:5314" Type: "CSeq", content: "3"
0.000006788 "rtsp.c:5314" Type: "Server", content: "AirTunes/366.0"
0.000006387 "rtsp.c:5314" Type: "Content-Type", content: "application/octet-stream"
0.000006554 "rtsp.c:5314" No Content Plist. Content length: 69.
0.000008616 "rtsp.c:1536" Responding with content of length 69
0.014536483 "rtsp.c:5252" Connection 2: Received an RTSP Packet of type "POST":
0.000031469 "rtsp.c:5254" Type: "Content-Length", content: "33"
0.000004987 "rtsp.c:5254" Type: "Content-Type", content: "application/octet-stream"
0.000003651 "rtsp.c:5254" Type: "CSeq", content: "4"
0.000005241 "rtsp.c:5254" Type: "DACP-ID", content: "1B1221F9052E490A"
0.000007743 "rtsp.c:5254" Type: "Active-Remote", content: "2455355829"
0.000007149 "rtsp.c:5254" Type: "User-Agent", content: "AirPlay/750.13.1"
0.000007347 "rtsp.c:5254" No Content Plist. Content length: 33.
0.000009516 "rtsp.c:2576" Connection 2: Unhandled POST /auth-setup Content-Length 33
0.000044648 "rtsp.c:2578" POST request
0.000007576 "rtsp.c:2578" Type: "Content-Length", content: "33"
0.000006749 "rtsp.c:2578" Type: "Content-Type", content: "application/octet-stream"
0.000006428 "rtsp.c:2578" Type: "CSeq", content: "4"
0.000007476 "rtsp.c:2578" Type: "DACP-ID", content: "1B1221F9052E490A"
0.000007499 "rtsp.c:2578" Type: "Active-Remote", content: "2455355829"
0.000007807 "rtsp.c:2578" Type: "User-Agent", content: "AirPlay/750.13.1"
0.000005651 "rtsp.c:2578" No Content Plist. Content length: 33.
0.000007271 "rtsp.c:5313" Connection 2: RTSP Response:
0.000007116 "rtsp.c:5314" Response Code: 200.
0.000006858 "rtsp.c:5314" Type: "CSeq", content: "4"
0.000006480 "rtsp.c:5314" Type: "Server", content: "AirTunes/366.0"
0.000007416 "rtsp.c:5314" No Content Plist. Content length: 0.
0.014039267 "rtsp.c:1335" Connection 2: Connection closed by client.The auth-setup page on the airplay site describes the steps to support HasUnifiedAdvertiserInfo. I wanted to give you a ping to get your thoughts before I dig into the auth steps to support this.
LemmoTresto
commented
10 months ago This is great, maybe this could also help with the homekit integration not showing what it is playing when someone else is playing it.
mikebrady
commented
10 months ago Thanks for the post, and thanks for the rvictl hint! Basically any progress that could be made on this front would be most welcome. The documentation on that site is indeed super.
Unfortunately, however, it looks as though HasUnifiedAdvertiserInfo enables a protocol that requires the device to have an Apple-approved IC -- the MFi chip, which seems to supply some kind of authentication information. Without it, we seem to be at a dead end. I'd love to be wrong about that!
MrMuetze
commented
10 months ago It seems for me this happens regularly when disconnecting from my raspberry pi and then shairport-sync crashes. I have used this setup together with my HomePod a lot in these situations. I also then get the message in my Apple TV as well. If I can help out with more tests or anything else just let me know. :)
mikebrady
commented
10 months ago It seems for me this happens regularly when disconnecting from my raspberry pi and then shairport-sync crashes. I have used this setup together with my HomePod a lot in these situations. I also then get the message in my Apple TV as well. If I can help out with more tests or anything else just let me know. :)
Thanks. If you could work out how to reproduce that crash, it would be useful!
MrMuetze
commented
10 months ago Ah when investigating this I had to realize that my crash is probably unrelated to the "Unable to connect" message. Might be more of a output_device_error_19 situation. I'll keep an eye on it though and see if it keeps happening after I hopefully improve the other situation. 😅
mikebrady
commented
10 months ago Ah when investigating this I had to realize that my crash is probably unrelated to the "Unable to connect" message. Might be more of a
output_device_error_19situation. I'll keep an eye on it though and see if it keeps happening after I hopefully improve the other situation. 😅
Thanks!
stevemurr
commented
10 months ago @mikebrady - As of this morning, I am no longer seeing this issue. I'm able to connect to an active session from all of my devices however volume, track position and play/pause are non-functional for devices who connect to an active session. However, next track is functional for devices connecting to an active session. If I leave all devices connected to the session they update song information correctly. Is anyone else seeing this behavior?
Note: If I add the speaker to the home app I get the same behavior as before - speaker adds but shows "no response" after approx. 1 minute.
aaronk6
commented
9 months ago @stevemurr @mikebrady I noticed that the openairplay guys have an experimental implementation of an AirPlay 2 receiver in Python here: https://github.com/openairplay/airplay2-receiver
I got it working and saw that the “Unable to Connect” issue does not occur when sending audio to this receiver and opening the AirPlay device list on another device. So it looks like they’re doing something right. 🙂
I guess from here, we could compare the RTSP messages and see what the differences are. @mikebrady, do you think this is a reasonable approach? If so, I’m happy to dive in.
By the way, I also took a look at the features that each receiver is announcing:
0x405f4200,0x1c3000x405FCA00,0x1C340So shareport-sync announces all the features that openairplay announces, plus:
(per https://openairplay.github.io/airplay-spec/features.html)
So HasUnifiedAdvertiserInfo is probably not the culprit here.
aaronk6
commented
9 months ago I made an interesting discovery today. It looks to me as if version 4.3 is not affected by the bug. I tried various versions, but only with version 4.3, the “Unable to Connect” message woudn’t appear.
I ran the following steps for each version:
Result:
| SPS Version | Behavior on iOS 17.2.1 |
|---|---|
| latest (4.3.2) | “Unable to connect” message |
| 4.3.1 | “Unable to connect” message |
| 4.3 | ✅ (“Unable to connect” didn’t show up) |
| 4.2 | “Unable to connect” message |
| 4.1.1 | Unreliable playback + “Unable to connect” message |
I tested with:
sudo docker run --net host --device /dev/snd mikebrady/shairport-sync:$VERSION -a shairport-test-$VERSION -vv(Where $VERSION is the respective version shown in the table above.)
I went over the table 3 times and got reproducible results.
@stevemurr Would you mind trying version 4.3 on your end to confirm my findings?
@mikebrady Any idea what this might be? I remember noticing the problem after you fixed the session interruption crashes in #1723. This coincided with the release of iOS 17 which could have led us on the wrong track.
herdingdata
commented
9 months ago Hello. I'm experiencing this issue too! Let me know if I can help with any troubleshooting info. I'm not running shairport-sync in a docker container, it's just installed direct to my pi. Are there any installation steps to switching version?
It's happening when I'm airplaying from an ipad (ipados 17.0.3) to my raspberry pi (shairport sync 4.3.2). The error itself appears on an apple tv on the same network (tvos 17.2). I've also seen it on the apple tv when airplaying from another macbook to the same pi - the macbook was just updated to sonoma 14.0 but it was occurring whilst said macbook was on ventura 13.x, though I believe tvOS was already 17.2 in all instances.
aaronk6
commented
9 months ago Hi @herdingdata! Did you build from source using this guide? If so, you can check out a specific version like this while in the source repo folder:
$ git checkout 4.3And then redo the usual steps to build and install.
Verify if it succeeded using:
$ shairport-sync -VMany thanks @aaronk6 and @herdingdata for your discoveries and comments. This "cannot connect" problem seems to be related to extra remote control protocols that, unfortunately, we don't seem to know too much about. The protocols also seem to be changing quite rapidly between different version of iOS and homePodOS. We have experimented with using different combinations of feature flags, but it's really hard to make out anything definitive. The version table produced by @aaronk6 is very useful, thanks, and we will review it. Separately, IRL, I'll be away from my computers until the end of January.
aaronk6
commented
8 months ago Hi @mikebrady, thanks for checking in! For the time being, I’ve downgraded to version 4.3 to work around the issue. Enjoy your time away from the computers! I’m happy to test any changes once you’re back. I’ve just updated my post above to indicate that these tests were performed on iOS 17.2.1. If helpful, I can re-run those tests on other iOS versions, too.
stevemurr
commented
8 months ago Hi @aaronk6 - I installed 4.3 and have confirmed that I no longer see the "Unable to Connect" messages.
There is a side effect of this version for me.
(Person A, Device A) - starts playback
(Person A, Device B) - no "Unable to Connect", can connect to a running session through the control center.
(Person B, Device A) - sees "Unable to Connect". Can see the running session, but the block will just say "tap to connect" and if the user taps this, the unable to connect dialogue is shown.
(Person A, Device A) - starts playback
(Person A, Device B) - no "Unable to Connect", is unable to connect to a running session through control center.
(Person B, Device A) - no "Unable to Connect". The running session is not visible in the control center.
My intuition for HasUnifiedAdvertiserInfo came from the Denon receiver on my network sent the HasUnifiedAdvertiserInfo bit and did not show unable to connect and was controllable through the control center from any person on the network.
I assumed Unable to Connect error is being shown when the device fails this auth handshake. I further assume that this auth handshake became mandatory in iOS 17 which also provides an explanation for homekit integration issues.
@mikebrady mentioned that to enable HasUnifiedAdvertiserInfo would possibly require a hardware chip for authentication to succeed. I think the hardware chip is required for mass market products.
However, there might be a workaround with the HomekitADK. I use shelly switches and flash them with this firmware to make them native homekit devices. This firmware generates the auth parts, but just notifies the user that the device is unverified.
Here is a snippet from that project, that shows the mfi token auth process.
static struct HAPPlatformMFiTokenAuth s_mfi_auth;
HAPPlatformMFiTokenAuthOptions mfi_opts = {};
HAPPlatformMFiTokenAuthCreate(&s_mfi_auth, &mfi_opts);
HAPPlatform platform = {
.keyValueStore = &s_kvs,
.accessorySetup = &s_accessory_setup,
.setupDisplay = nullptr,
.setupNFC = nullptr,
.ip =
{
.tcpStreamManager = &s_tcpm,
.serviceDiscovery = &s_service_discovery,
},
.ble =
{
.blePeripheralManager = nullptr,
},
.authentication =
{
.mfiHWAuth = nullptr,
.mfiTokenAuth = &s_mfi_auth,
},
};@aaronk6 - thanks for joining in on this! Let me know what you think of the above.
github-actions[bot]
commented
6 months ago This issue has been inactive for 28 days so will be closed 7 days from now. To prevent this, please remove the "stale" label or post a comment.
aaronk6
commented
6 months ago @stevemurr I didn’t find the time yet to have a detailed look at your findings and get back to you. I promise to do that soon!
@mikebrady In the meantime, can you reopen the issue? I’m really hoping that we find a solution here because I’m stuck on version 4.3 because of this.
aaronk6
commented
1 week ago I’ve revisited this with shairport-sync 4.3.4 and iOS 18.0 and it seems the error is gone. I will monitor this carefully over the coming days, but my steps to reproduce from above don’t lead to the error anymore:
@stevemurr Would you mind trying this on your end? Apologies for not getting back earlier!
What happened?
I’m frequently getting “Unable to connect” messages on iOS 17.x and tvOS 17.x. What’s interesting about these messages is that they appear without me actually selecting a speaker. Simply opening a the speaker selection view on iOS is enough. Sometimes not even that. However, when I then actually select to a speaker, it connects just fine.
Screencast:
https://github.com/mikebrady/shairport-sync/assets/446063/cfb4cd80-9f1a-43ca-98ad-657535061f30
The issue seems to occur when Shairport Sync is already playing something on that speaker. My setup is that I’m constantly playing audio via OwnTone to Shairport Sync to have music in the bathrooms, but allow clients to override the stream (using
allow_session_interruption = "yes"in the Shairport Sync config). Now that https://github.com/mikebrady/shairport-sync/issues/1723 is fixed, overriding an existing session works perfectly.So it’s really “just” the “Unable to Connect” message, which is—at first glance—a cosmetic issue, but it can get very annoying as it sometimes also occurs when the iPhone is just lying on the table and streaming music. It will turn on the display just for showing this message. On the Apple TV, it will even interrupt a running show.
![IMG_7229]()
It’s also worth noting that this only happens on Shairport Sync receivers. Besides these, I have a Denon AVR X1700H, which is also AirPlay 2-compatible, and two HomePods.
I believe this started after upgrading to iOS 17 and tvOS 17 which includes some changes in regards to AirPlay. For example, it will proactively suggest to connect to an AirPlay speaker if you start to play something on the iPhone. My hunch is that iOS is regularly trying to probe speakers to see if they can be offered as AirPlay targets. Shairport Sync seems to reply to this request in a way that triggers this message.
The attached log output is shown when I open the speaker selection view on iOS while OwnTone is streaming to the Bad DG speaker.
@mikebrady, you wrote here that this might be tough one. I’m reporting it anyway to see if other people experience this, too, and maybe we will find out eventually how to adhere more closely to the protocol to prevent this message from showing up.
Relevant log output
System Information.
Raspberry Pi 4, multiple Shairport Sync instances using Docker
Configuration Information.
PulseAudio or PipeWire installed?
How did you install Shairport Sync?
Docker
Check previous issues