Streaming & Pairing Timing Out
Closed this issue · 8 comments
Running iOS 15 Public Beta 3 (iPhone 11)
Current -> 265f050
Streaming times out & HomeKit pairing shows "Unable to Add Accessory" instantly
4f4ac82
Stream times out & HomeKit pairing sits at "Connecting to Speaker" before it times out.
Wasn't actually able to find the last functioning commit, though I didn't try them all as I have limited time.
Not sure what's happened. Will edit / comment with any information as I find it.
I cleared what was in the pairings/
directory, and now the latest commit pairs to HomeKit successfully (984a98c)
Streaming still appears to be a problem. After restarting (after I paired the receiver with HomeKit), I was able to get to Pair-Setup 1/2 before my device stopped attempting to stream. After a further restart, I got to POST /fp-setup
and then it looks like the receiver sent an EVENT which was never acknowledged by the iDevice.
Last message in console was Loading ed25519 keypair for b'aa5cb8df-7f14-4249-901a-5e748ce57a93'
Almost forgot, the -npm
flag needed to be passed. I can confirm that pairing & streaming works to the current branch, but it's not "out-of-the-box". It requires disabling this speaker as the PTP master, which isn't ideal nor is it the first idea I'd have if I didn't already have prior knowledge of this code.
Speaking of having to disable PTP master, where are we at with properly implementing PTP? I would assume a proper implementation of it would fix the need to pass this flag to make it work.
We can disable this flag as a default, then make it default when PTP is added. I think the PTP flag changes some (other) airplay beahviour, in general for the better (without HK or HAP stuff going on). I don't remember, but might have been NTP and SDP (which mandates FairPlay encryption...?).
It requires disabling this speaker as the PTP master, which isn't ideal nor is it the first idea I'd have if I didn't already have prior knowledge of this code.
Hoe do you currently do that?
Use the -npm
flag.
I had a play around with HAP-Python and it seems pretty solid. I'll play around with using the smart speaker type next, then hopefully we can replace our HAP code with HAP-Python as a dependency (unless we don't want to use HAP-Python)
Yeah - it's pretty sweet. Either way, a speaker in HAP or HAP in AP2, there's a bit of lifting to do. HAP doesn't understand FP encryption, I think, and the HAP zeroconf mDNS stuff would need extending to account for the special broadcast needs of AP2. But multi-threading the connections is worthwhile.
Use the
-npm
flag.
I was somewhere in node package manager land in my thoughts...
I've been testing HK functionality recently - and made some improvements. It's not the SDK way of doing things, but HK works well enough now. Some other reconnect fixes also.
Did you come anywhere/way with this?