mDNS browse triggers ANOTHER_SERVER goodbye and disconnects players

[1liminal1]

Sendspin CLI version: 5.9.0 (aiosendspin 4.4.0) Music Assistant version: 2.8.0rc3 OS: Raspberry Pi OS (4x Raspberry Pi players) Setup: Single MA server, 4 sendspin daemon players (kitchen, bedroom, bathroom, living-room), 1 ESPHome player (powered off)

Description

Sendspin daemon players periodically disconnect with GoodbyeReason.ANOTHER_SERVER and immediately reconnect to the same server ~40ms later. Only one MA server is running. This kills playback on the affected players every time it occurs.

Reproduction

Running avahi-browse -rt _sendspin._tcp from any Pi on the network reliably triggers the disconnect. Players send client/goodbye with reason ANOTHER_SERVER, then immediately reconnect with client/hello back to the same server. This is 100% reproducible.

Periodic occurrence

Without manual intervention, this happens roughly every 56 minutes. I believe MA's periodic mDNS discovery scan is triggering the same behaviour. Timestamps from a single day:

• 15:26:36
• 16:22:51
• 17:19:06
• 18:15:21
• 18:21:35

Affected vs unaffected players

Only players whose mDNS records successfully resolve during the browse are affected. Players that time out during resolution are unaffected:

Player	Band	AP	mDNS resolves	Disconnects
Kitchen	5GHz	AP-A	✅ Yes	✅ Yes
Bedroom	5GHz	AP-A	✅ Yes	✅ Yes
Bathroom	2.4GHz	AP-B	❌ Timeout	❌ No
Living Room	2.4GHz	AP-B	❌ Timeout	❌ No

This confirms the disconnect is triggered by the mDNS interaction itself, not by an actual second server.

Server-side logs (MA)

18:21:35.782 DEBUG [aiosendspin.server.connection.kitchen] Received client/goodbye with reason: GoodbyeReason.ANOTHER_SERVER
18:21:35.782 DEBUG [aiosendspin.server.connection.kitchen] Writer cancelled
18:21:35.782 DEBUG [aiosendspin.server.connection.unknown-client] Connection established
18:21:35.783 DEBUG [aiosendspin.server.client.kitchen] Skipping cleanup scheduling (reason: GoodbyeReason.ANOTHER_SERVER)
18:21:35.783 DEBUG [aiosendspin.server.connection.kitchen] Connection disconnected
18:21:35.783 DEBUG [aiosendspin.server.connection.kitchen] WebSocket closed, close_code=1000
18:21:35.783 DEBUG [aiosendspin.server.server] Not reconnecting after goodbye reason another_server
18:21:35.812 DEBUG [aiosendspin.server.connection.bedroom] Received client/goodbye with reason: GoodbyeReason.ANOTHER_SERVER

18:21:35.812 DEBUG [aiosendspin.server.connection.bedroom] Writer cancelled

18:21:35.813 DEBUG [aiosendspin.server.connection.unknown-client] Connection established

18:21:35.814 DEBUG [aiosendspin.server.client.bedroom] Skipping cleanup scheduling (reason: GoodbyeReason.ANOTHER_SERVER)

18:21:35.814 DEBUG [aiosendspin.server.connection.bedroom] Connection disconnected

18:21:35.814 DEBUG [aiosendspin.server.connection.bedroom] WebSocket closed, close_code=1000

18:21:35.814 DEBUG [aiosendspin.server.server] Not reconnecting after goodbye reason another_server

Players immediately reconnect:

18:21:35.823 DEBUG [aiosendspin.server.connection.kitchen] Received client/hello: ClientHelloPayload(client_id='kitchen', name='Kitchen', version=1, ..., software_version='aiosendspin 4.4.0')
18:21:35.852 DEBUG [aiosendspin.server.connection.bedroom] Received client/hello: ClientHelloPayload(client_id='bedroom', name='Bedroom', version=1, ..., software_version='aiosendspin 4.4.0')

Expected behaviour

An mDNS browse of _sendspin._tcp should not cause connected players to disconnect from their current server. Players should only send ANOTHER_SERVER goodbye when an actual different server attempts to connect.

[1liminal1]

Update: GitHub Copilot agent analysed this and identified the root cause in sendspin/daemon/daemon.py.
When a new server connection arrives via mDNS, _handle_server_connection doesn't check if it's from the same server already connected. It treats every incoming connection as a new server, sends ANOTHER_SERVER goodbye, disconnects, then immediately reconnects to the same server.
Proposed fix is to track the connected server's peer address and skip duplicate connections:
python# In init:
self._server_peer: str | None = None

In _handle_server_connection, before acquiring the lock:

new_peer = ws.get_extra_info('peername')[0]
if self._client is not None and self._client.connected and self._server_peer == new_peer:
logger.info("Ignoring duplicate connection from same server")
return

After successful handshake:

self._server_peer = new_peer

On disconnect:

self._server_peer = None
Screenshots of the full diff attached.

[1liminal1]

Update: Root cause identified and local patch applied

The issue is in sendspin/daemon/daemon.py in _handle_server_connection. When a new WebSocket connection arrives (triggered by mDNS re-discovery), the daemon doesn't check if it's from the same server already connected. It unconditionally sends ANOTHER_SERVER goodbye, disconnects, then immediately reconnects to the same server.

Fix

Track the connected server's peer address and skip duplicate connections from the same server:

# In __init__, add peer tracking:
self._server_peer: str | None = None

# At the top of _handle_server_connection, before acquiring the lock:
new_peer = ws._req.remote  # type: ignore[union-attr]
if self._client is not None and self._client.connected and self._server_peer == new_peer:
    logger.info("Ignoring duplicate connection from same server")
    await ws.close()
    return

# After successful handshake:
self._server_peer = new_peer

# In the finally block on disconnect:
self._server_peer = None

Result

After applying this patch, running avahi-browse -rt _sendspin._tcp no longer causes players to disconnect. Previously this was 100% reproducible. Music continues playing uninterrupted through mDNS browse events.

Tested on sendspin 5.9.0 / aiosendspin 4.4.0 on Raspberry Pi OS.