Unable to Pair Roon Server with Hisense 65U7S PRO via AirPlay (ref#LA12K6)

rdse · June 9, 2026, 8:35am

Hi! What’s not quite right with Roon?

· None of the above quite fits

None of the above quite fits

· None of these quite match

Tell us what's going on

· Roon Server (Linux) 2.67 build 1661 can't pair with Hisense 65U7S PRO over AirPlay
Server try logs:
06/09 08:24:46 [Local 06/09 11:24:46] Info: [transport] created zone Hisense
06/09 08:24:46 [Local 06/09 11:24:46] Info: [transport] with endpoint Hisense (65U7SE) (23:1:98330ba0-df83-01f4-f0e6-403b9872f651) [IsAvailable=True]
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] Sending pair-verify #1
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [zone Hisense] Loaded Queue=0 Tracks Swim=Inactive AutoSwim=True Loop=Disabled Shuffle=False
06/09 08:24:46 [Local 06/09 11:24:46] Warn: [airplay/clientV2] [192.168.80.144] pair-verify #1 failed: 403 Forbidden, attempting pairing
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] pair-setup-pin
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] Sending pair-setup-pin #1
06/09 08:24:46 [Local 06/09 11:24:46] Warn: [airplay/clientV2] [192.168.80.144] pair-setup-pin #1 failed: 403 Forbidden, attempting pairing
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] Sending pair-verify #1
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] pair-setup fail
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] pair-verify #1 Succeeded
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] Sending pair-verify #2
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] pair-verify #2 Succeeded
06/09 08:24:46 [Local 06/09 11:24:46] Trace: [airplay/clientV2] [192.168.80.144] Requesting OPTIONS
06/09 08:24:46 [Local 06/09 11:24:46] Info: [airplay/clientV2] [192.168.80.144] REQUESTING OPTIONS *
06/09 08:24:56 [Local 06/09 11:24:56] Debug: [easyhttp] [1478] POST to https://api.roonlabs.net/device-map/1/register returned after 167 ms, status code: 200, request body size: 3 KB
06/09 08:24:56 [Local 06/09 11:24:56] Trace: [devicemap] device map updated
06/09 08:24:56 [Local 06/09 11:24:56] Warn: [airplay/clientV2] [192.168.80.144] in _TimingBeginRecv async cb: Operation canceled
06/09 08:24:56 [Local 06/09 11:24:56] Warn: [airplay/rtsp] IOException in RTSP request: Unable to read data from the transport connection: Connection timed out.
06/09 08:24:56 [Local 06/09 11:24:56] Warn: [airplay/clientV2] [192.168.80.144] in _ControlBeginRecv async cb: Operation canceled
06/09 08:24:56 [Local 06/09 11:24:56] Warn: [airplay/clientV2] [192.168.80.144] OPTIONS failed: Result[Status=NetworkError]
06/09 08:24:56 [Local 06/09 11:24:56] Warn: [airplay/clientV2] [192.168.80.144] Failed to get OPTIONS: Result[Status=NetworkError]
06/09 08:24:56 [Local 06/09 11:24:56] Trace: [airplay/clientV2] [192.168.80.144] Connecting to airplay server

Tell us about your home network

· Wi-Fi network on Xiaomi AIoT AC2350

connor · June 9, 2026, 9:31pm

Hi @rdse,

Thank you for your post. We’ve examined the diagnostics you’ve shared along with logs from the device. We see the Airplay pairing actually succeeding, but then the RTSP connection breaks down when Roon starts sending media.

Is this TV hardwired or relying on WiFi? What about the RoonServer machine? Also, we recommend you make sure the router is forwarding multicast traffic in a manner AirPlay2 expects. Do you have any settings visible related to IGMP snooping or multicast forwarding, and what are they set to currently?

Have you tried adding the TV to the Apple Home app outside of Roon on a phone or computer?

Lastly, can you pair with this TV via AirPlay outside of Roon on an iPhone or computer?

We’ll watch for your reply and proceed from there. Thanks!

rdse · June 10, 2026, 10:59am

Hi Connor, thank you for looking into this.

To answer your questions first:

The TV is connected via Wi-Fi to the router (Xiaomi AC2350 running OpenWRT). The Roon Server machine is hardwired — it runs in an LXC container on a Proxmox host, bridged to the LAN (no NAT, single interface, same subnet: container 192.168.80.13/24, TV 192.168.80.144/24).
Yes, pairing with this TV via AirPlay from a MacBook Pro (Wi-Fi) works flawlessly every time.
I have not tried the Apple Home app, but I can if it would help.

Since your reply, I’ve systematically checked and ruled out the network layer:

1. Firewalls. Proxmox firewall is fully disabled (datacenter, node and container level). iptables-save on the host shows empty rulesets with ACCEPT policies. No firewall inside the container.

2. Container networking. The LXC has a single eth0 bridged to vmbr0, correct subnet, no extra interfaces, no NAT, no Docker bridges.

3. IGMP snooping / multicast forwarding (your main question). On the OpenWRT router, multicast snooping on br-lan is disabled (/sys/class/net/br-lan/bridge/multicast_snooping = 0, no igmp/multicast options set in UCI), so the router floods multicast to all ports including Wi-Fi. On the Proxmox bridge (vmbr0), snooping was enabled (=1); I disabled it and retested — no change in behavior.

4. Packet capture. I ran tcpdump on the container’s interface during a pairing attempt. The unicast TCP path is completely clean: three-way handshake to TV:7000, the full pair-verify exchange goes back and forth with no retransmissions or loss. Then Roon sends the encrypted OPTIONS request (consistent with the REQUESTING OPTIONS * log line), and the TV ACKs the TCP segments but never sends an application-level reply. Ten seconds of silence, then Roon closes the connection with FIN — matching the IOException in RTSP request: Connection timed out in the logs. mDNS and SSDP multicast from the TV are visible in the capture throughout, so basic multicast delivery to the container works.

So to summarize what the capture shows: pair-verify #1 and #2 succeed (session keys are negotiated), the TV receives and TCP-acknowledges the first encrypted RTSP request (OPTIONS), and then simply does not respond at the application level. This happens before any PTP/timing or SETUP phase. Given that firewalls, container networking, and IGMP snooping on both bridges have been ruled out, and that an Apple device pairs with the same TV without issues, this looks like an interoperability problem between Roon’s AirPlay 2 client and this TV’s firmware on the encrypted RTSP channel, rather than a network issue.

TV details from its mDNS TXT record: model 65U7SE (65U7S PRO), srcvers 377.40.00, fv p20.09.5013.260115, features 0x7F8AD0,0x38BCF46.

I can provide the full packet capture (pcap) if that helps your team. Happy to run any additional tests.

rdse · June 10, 2026, 11:21am

One more data point that isolates this further: I configured Roon to stream via AirPlay to my MacBook (acting as an AirPlay receiver), and then forwarded the audio from the Mac to the TV via AirPlay. This double-hop chain works — audio plays on the TV. So Roon’s AirPlay sender works fine from this exact container through this exact network path (it streams to the Mac without issues), and the TV’s AirPlay receiver works fine with an Apple client. The only failing combination is Roon’s client talking directly to this TV’s AirPlay 2 implementation.

vadim · June 12, 2026, 10:07am

Hello @rdse

We’ve discussed this with our senior QA and development teams. The team is investigating some possibilities here and, as soon as that investigation is complete, we’ll be sure to follow up ASAP.

You have our apologies for the trouble here, and we’ve greatly appreciated your patience as we continue investigating this tricky issue. We’ll be in touch as soon as we can.