Hey @Chris_Keller,
Thanks for the detailed report. We were able to review a fresh set of Roon Server logs for a closer look. The line you spotted is a good catch, but it isn’t the cause.
The 400 Bad Request predates the problem. It first appears on 09/07 at 06:10 local, a week before the trouble started, while the Küche HomePod was playing normally. It occurs 23 times across your logs, and every time it’s followed within a second by a clean ANNOUNCE → SETUP → RECORD. Roon Server tries the AirPlay 2 handshake, the HomePod declines, and Roon Server falls back to AirPlay 1. That’s always been how this HomePod is driven.
What did change: the HomePod stopped answering. A healthy AirPlay receiver sends two things back, retransmit requests when it loses a packet, and DACP volume updates. Both appear every day in your logs through 09/14 morning. The last retransmit request is at 08:06 local, the last volume push at 06:10.
From your first failed attempt at 21:05 local onward, across a dozen sessions including one that ran 108 minutes, the HomePod sent back neither, not once, while accepting every command Roon Server issued.
Two things to try. First, check in the Home app that the HomePod isn’t half of a stereo pair, set as a TV’s default speaker, or in a group, any of those will make it refuse third-party AirPlay 1 audio. Then send to it from an AirPlay-1-only source such as shairport-sync. If that’s silent too, this is a receiver-side regression in OS 27 rather than something we can work around in Roon Server.
One note so it doesn’t look like a second fault: the HomePod’s AirPlay ID changed at 22:13 local when it was reset, so Roon Server built a fresh zone with default settings. That’s why the setup had to be redone.
It might be worth testing the AirPlay compatibility toggle as well to see if that helps. You can find that within your audio device settings in Roon.
Let us know what the AirPlay-1-only test gives you. 