pair-setup fails with M4 error 2 on TCL Roku TV (8118X, Roku OS 15.3.4) and macOS (Mac15,14) — code and password modes

[jeffjacobsen]

Summary

pair-setup fails with M4 error: 2 against every receiver we tested — a TCL Roku TV (both "require code" and password modes, fresh on-screen codes entered promptly) and a Mac Studio (both code and password modes). The connection and code-request steps work (both receivers display pairing codes on request), but the SRP verification is rejected at M4 every time. Since a Roku Stick 4K is confirmed working in the README and #19 implies a Roku Express 4K streams, this looks like a receiver-family-specific gap in pair-setup rather than user error.

Environment

• Sender: Raspberry Pi 5, Debian 13 (trixie) arm64, labwc (wlroots) + xdg-desktop-portal-wlr, Go 1.25, doubletake f4b3a44 (2026-08-08)
• Receiver A: TCL Roku TV 32S325 (model number 8118X), Roku OS 15.3.4 build 832, AirPlay enabled
• Receiver B: Mac Studio (Mac15,14), AirPlay Receiver enabled (srcvers=950.7.1 in its mDNS TXT)

What happens

Receiver A (Roku TV), "Require code — first time only", -pair mode; a 4-digit code appears on the TV, entered within ~25–40 s:

2026/08/08 13:30:55 connected to: 32in TCL Roku TV (model: 8118X, initialVolume: 0.0)
Enter the code shown on the receiver, or its configured password: 2026/08/08 13:31:32 PIN pairing failed: pair-setup: pair-setup M4 error: 2

(Reproduced twice with fresh codes.)

Receiver A with an AirPlay password configured instead (no on-screen code shown, password entered at the prompt):

2026/08/08 13:22:04 connected to: 32in TCL Roku TV (model: 8118X, initialVolume: 0.0)
Enter the code shown on the receiver, or its configured password: 2026/08/08 13:22:04 PIN pairing failed: pair-setup: pair-setup M4 error: 2

Also observed on the TV without -pair (transient first, then PIN attempt) — the second attempt in quick succession gets rate-limited:

2026/08/08 13:21:08 connected to: 32in TCL Roku TV (model: 8118X, initialVolume: 0.0)
2026/08/08 13:21:09 transient pairing failed: pair-setup: pair-setup M4 error: 2, prompting for PIN
Enter the code shown on the receiver, or its configured password: 2026/08/08 13:21:09 PIN pairing failed: pair-setup: pair-setup M2 error: 3

Receiver B (Mac Studio), on-screen code mode (-pair, fresh code entered within ~25 s):

2026/08/08 13:37:42 connected to: Mac Studio (model: Mac15,14, initialVolume: 0.0)
Enter the code shown on the receiver, or its configured password: 2026/08/08 13:38:06 PIN pairing failed: pair-setup: pair-setup M4 error: 2

Receiver B with a configured AirPlay password (verified correct — freshly set for the test): identical M4 error: 2.

With no password configured on the Mac, the code-display trigger is refused there (warning: failed to trigger PIN display: pair-pin-start: HTTP 400), while the Roku TV accepts pair-pin-start and shows its code — so the pre-M1 steps behave as expected on both.

Expected

Pairing completes, as it does on the Roku Stick 4K (3820R2) noted in the README.

Notes

• Four configurations (2 receivers × code/password modes), all failing at the same message with correct secrets, suggests the SRP proof/parameters in pair-setup don't match what these receiver families expect — Roku TV firmware (8118X-class) and current macOS both.
• Happy to test patches/branches — the sender environment is a persistent Pi 5 test rig and re-testing is quick.

[jeffjacobsen]

Follow-up: we debugged this to root cause and now have screen mirroring working end-to-end on the TCL Roku TV (8118X, Roku OS 15.3.4) with three changes. Working diff at the bottom; each finding was confirmed against real hardware tonight.

Finding 1 — PIN pairing sends X-Apple-HKP: 5; non-AppleTV receivers only accept 3 (SystemPairing)

This was the cause of the M4 error 2 in this issue. Type 5 (screen-capture pairing with the OPACK ACL) appears to be understood by Apple TVs only — receiver implementations document the observed HKP set as 0, 2, 3, 4, 6, 7 with 3 = SystemPairing (the display-a-code flow). Under type 5, both the TCL Roku TV and a macOS receiver (Mac15,14) reject the SRP proof at M4 even with a verified-correct code/password; with type 3 both accept it immediately. The SRP math itself checked out fine against known-good implementations (srptools conventions), so no crypto changes were needed.

With the change, the type-5-specific ScreenCapture ACL should only be attached for type 5 (second hunk of the diff). Note: hardcoding 3 may regress the Apple TV screen-capture path — a proper fix probably selects 5 vs 3 based on the receiver (model/features), keeping 5 for Apple TVs.

Finding 2 — transient pairing uses an empty SRP password; the AirPlay 2 convention is "3939"

pairSetupTransient calls completeSRPExchange(ctx, "", …). Receivers implementing standard transient pairing derive their verifier from the fixed password 3939 (see e.g. openairplay/airplay2-receiver hap.py: srp.SRPServer(b"Pair-Setup", b"3939")), so the proof can never match. This was invisible on the Roku Stick 4K because performTransientSetupAndVerify tries the raw binary (UxPlay-style) pair-setup first and the Stick accepts it — the SRP transient path likely never ran on the tested receiver.

Finding 3 — the modern (encrypted) session path requires a PTP clock; Roku TVs are NTP-only

After pairing succeeded, SETUP failed with configure PTP media clock: SETUP response omitted timingPeerInfo.ClockID. The TCL never returns a PTP ClockID — it only speaks NTP-style timing. Two issues compound:

• timingProtocolForSession hardwires PTP for encrypted sessions;
• the modernControlSetup branch calls clock.configureFromSetup(...) unconditionally, while the legacy branch guards it with timingProtocol == timingProtocolPTP.

In the diff below we bluntly force NTP for the experiment (plus mirror the legacy guard); the proper fix is presumably to keep requesting PTP and fall back to NTP when the SETUP response omits timingPeerInfo.ClockID (or select by receiver features), so Apple TVs keep PTP. The existing nil-guards on s.mediaClock in the frame/audio senders already handle the NTP case correctly.

Result

With all three changes on a Raspberry Pi 5 (Debian 13, labwc/wlroots + xdg-desktop-portal-wlr, chooser_type=none):

connected to: 32in TCL Roku TV (model: 8118X, initialVolume: 0.0)
Enter the code shown on the receiver, or its configured password: credentials saved (file)
pairing complete
FairPlay SAP unsupported (…); continuing with pair-verify DataStream setup
[CAPTURE] auto bitrate selected: 4147 kbps for 1920x1080@30fps
[CAPTURE] using OpenH264 software encoding (openh264enc)
screen capture started
mirror session ready (data port: 55244)
audio capture started

…and the TV shows the Pi's screen. Saved credentials reconnect without a new code on subsequent runs. (Small packaging note: the capture prerequisite check shells out to gst-inspect-1.0, so gstreamer1.0-tools is effectively a required dependency alongside the plugin packages — worth adding to the README's apt line, as its absence is reported as "pipewiresrc plugin not found" even when gstreamer1.0-pipewire is installed.)

macOS receiver status with these patches: proof accepted (M4 passes), but password-mode pairing then fails at M6 error 7 — likely because password auth is per-session/transient-style and the M5/M6 identity exchange shouldn't run there. Not investigated further.

Happy to split any of this into PRs if useful.

Diff (experiment quality — see caveats above)

diff --git a/internal/airplay/mirror.go b/internal/airplay/mirror.go
index 0a53022..c551f49 100644
--- a/internal/airplay/mirror.go
+++ b/internal/airplay/mirror.go
@@ -149,8 +149,12 @@ func sourceVersionForSession(encrypted bool) string {
 }
 
 func timingProtocolForSession(encrypted bool) string {
+	// EXPERIMENT (VAL): Roku TVs (e.g. TCL 8118X) pair via HAP but their
+	// SETUP response carries no timingPeerInfo.ClockID — they only speak
+	// NTP-style timing. Request NTP regardless of encryption; receivers
+	// that prefer PTP still advertise it in their SETUP response.
 	if encrypted {
-		return timingProtocolPTP
+		return timingProtocolNTP
 	}
 	return timingProtocolNTP
 }
@@ -433,8 +437,13 @@ func (c *AirPlayClient) setupMirrorSession(ctx context.Context, cfg StreamConfig
 			return nil, err
 		}
 		skipRecord, _ = controlResp["skipRecord"].(bool)
-		if err := clock.configureFromSetup(controlResp, controlHeaders, receivedAt); err != nil {
-			return nil, fmt.Errorf("configure PTP media clock: %w", err)
+		// EXPERIMENT (VAL): only configure the media clock when PTP was
+		// negotiated — NTP receivers (Roku TVs) return no timingPeerInfo,
+		// mirroring the guard the legacy branch below already has.
+		if timingProtocol == timingProtocolPTP {
+			if err := clock.configureFromSetup(controlResp, controlHeaders, receivedAt); err != nil {
+				return nil, fmt.Errorf("configure PTP media clock: %w", err)
+			}
 		}
 		receiverEventPort = plistInt(controlResp["eventPort"])
 		if err := connectEvent(); err != nil {
diff --git a/internal/airplay/pairing.go b/internal/airplay/pairing.go
index a25594a..099fa73 100644
--- a/internal/airplay/pairing.go
+++ b/internal/airplay/pairing.go
@@ -62,7 +62,11 @@ const (
 // its own system-pairing type and ACL; transient pairing is a separate type.
 const (
 	pairingTypeTransient     = 4
-	pairingTypeScreenCapture = 5
+	// EXPERIMENT (VAL): was 5 ("screen capture" pairing, sniffed from current
+	// macOS→AppleTV). Non-AppleTV receivers (TCL Roku TV, macOS receiver)
+	// reject the SRP proof under type 5 — documented receiver values are
+	// 0,2,3,4,6,7 with 3 = SystemPairing (the display-a-code flow).
+	pairingTypeScreenCapture = 3
 )
 
 const defaultPairingClientName = "doubletake device"
@@ -257,8 +261,9 @@ func (c *AirPlayClient) pairSetupTransient(ctx context.Context) error {
 		return fmt.Errorf("M2: missing server public key")
 	}
 
-	// SRP-6a exchange with empty PIN for transient
-	return c.completeSRPExchange(ctx, "", serverSalt, serverPub)
+	// SRP-6a exchange — transient pairing uses the fixed HAP password "3939"
+	// (HomeKit/AirPlay2 convention; see openairplay/airplay2-receiver hap.py)
+	return c.completeSRPExchange(ctx, "3939", serverSalt, serverPub)
 }
 
 // StartPINDisplay triggers the PIN display on the Apple TV.
@@ -443,7 +448,10 @@ func (c *AirPlayClient) completeSRPExchange(ctx context.Context, pin string, sal
 		{Tag: tlvPublicKey, Value: c.PairKeys.Ed25519Public},
 		{Tag: tlvSignature, Value: signature},
 	}
-	if c.effectivePairType() == pairingTypeScreenCapture {
+	// EXPERIMENT (VAL): the ScreenCapture ACL belongs to HKP type 5 only —
+	// under SystemPairing (3) it's an unexpected TLV. Send it only when the
+	// pair type is actually 5.
+	if c.effectivePairType() == 5 {
 		subTLVItems = append(subTLVItems, tlv8Item{Tag: tlvACL, Value: []byte(screenCaptureACL)})
 	}
 	subTLV := tlv8EncodeOrdered(subTLVItems)

[omarroth]

Looks like a regression, tested again locally, should be fixed with 55d3fe2.