### System details

ASUS TUF Dash F15 FX516PR_FX516PR (1.6)  11th Gen Intel(R) Core(TM) i7-11376H (8) @ 4.86 GHz GeForce RTX 3070 Mobile / Max-Q  Iris Xe Graphics Software: Omarchy 4.0.2-1  stable  Linux 7.1.9-archl-2  Hyprland 0.56.2 (Wayland)  ghostty 1.3.1-arch2  1042 (pacman) 

### What's wrong?


# Bluetooth A2DP sink silently stuck at `bluez5.profile = "off"` after reconnect, despite `Active Profile: a2dp-sink` and `connection: connected`

## Summary

After a Bluetooth headset reconnects (via a UI Bluetooth toggle, a `pipewire`/`wireplumber` service restart, or the headset's own power cycle), the resulting PipeWire sink often looks completely healthy on the surface — it's listed, marked default, reports `api.bluez5.connection = "connected"`, and even correctly negotiates the last-used codec (`aptx_hd` in this case) — but no audio ever plays. Streams routed to the sink get stuck in `[init]` and never reach `[running]`.

The underlying cause appears to be that the card's `bluez5.profile` property gets stuck at `"off"` while the card's `Active Profile:` label simultaneously reports `a2dp-sink`. These two values disagree and stay disagreeing — restarting `pipewire`/`pipewire-pulse`/`wireplumber`, or manually forcing `pactl set-card-profile <card> off` then `a2dp-sink`, does not resolve the mismatch. The only fix found so far is fully removing the Bluetooth device pairing (`bluetoothctl remove <MAC>`), re-pairing from scratch, and then restarting `wireplumber` again afterward (WirePlumber does not reliably notice the freshly re-paired device on its own).

## Environment

- Distro: Omarchy (Arch-based, Hyprland)
- `pipewire`: 1.6.8-1
- `pipewire-pulse`: 1.6.8-1
- `pipewire-alsa`: 1.6.8-1
- `pipewire-audio`: 1.6.8-1
- `wireplumber`: 0.5.15-1
- `bluez`: 5.87-2
- `bluez-utils`: 5.87-2
- Headset: Sennheiser MOMENTUM 5 Wireless (Bluetooth 5.4, codecs SBC / AAC / aptX / aptX HD / aptX Adaptive)
- Device MAC: `80:C3:BA:B8:06:72`

## Steps to reproduce

Any of the following reliably trigger the issue:

1. Toggle Bluetooth off/on via the desktop's quick-settings UI while the headset is connected (this performs a hard `rfkill block` / `rfkill unblock` cycle, not a soft radio toggle).
2. Restart the audio user services (`systemctl --user restart pipewire pipewire-pulse wireplumber`) while a Bluetooth sink is the active output.
3. Power-cycle the headset itself via its physical power button.

After any of the above, check the card state:

```
pactl list cards | grep -A 30 "bluez_card.<MAC_with_underscores>"
```

## Expected behavior

`bluez5.profile` should match `Active Profile:` and the sink should transition to `RUNNING` when a stream is pushed to it.

## Actual behavior

```
bluez5.profile = "off"
...
Active Profile: a2dp-sink
```

Sink stays `SUSPENDED` even when a client (e.g. Spotify) is actively pushing audio and the stream link shows `[init]` rather than `[running]`. No sound is produced. This persists across:

- `systemctl --user restart pipewire pipewire-pulse wireplumber`
- `pactl set-card-profile <card> off` followed by `pactl set-card-profile <card> a2dp-sink` (profile briefly reports as requested but reverts / never actually flips `bluez5.profile`)
- `pactl suspend-sink <sink> 0`

## Relevant logs

Every reconnect (successful or not) logs this from `bluetoothd`, regardless of outcome:

```
bluetoothd[878]: profiles/audio/a2dp.c:load_remote_sep() Unable to load LastUsed: rseid 8 not found
```

Correlating this with WirePlumber's own D-Bus registrations shows the sender ID for the A2DP media endpoints changing on every single reconnect:

```
bluetoothd[878]: Endpoint unregistered: sender=:1.387 path=/MediaEndpoint/A2DPSink/aptx_hd
...
bluetoothd[878]: Endpoint registered: sender=:1.396 path=/MediaEndpoint/A2DPSink/aptx_hd
...
(later, after another reconnect)
bluetoothd[878]: Endpoint unregistered: sender=:1.396 path=/MediaEndpoint/A2DPSink/aptx_hd
bluetoothd[878]: Endpoint registered: sender=:1.418 path=/MediaEndpoint/A2DPSink/aptx_hd
```

Full capture of one failure sequence, triggered by the UI Bluetooth toggle (hard rfkill cycle):

```
Sep 05 21:53:21 omarchy rfkill[549851]: block set for type bluetooth
Sep 05 21:53:26 omarchy systemd[1]: systemd-rfkill.service: Deactivated successfully.
Sep 05 21:53:27 omarchy rfkill[549964]: unblock set for type bluetooth
Sep 05 21:53:27 omarchy blueman-applet[1256]: blueman-applet WARNING PowerManager:186 on_adapter_property_changed: adapter powered on while in off state, turning bluetooth on
Sep 05 21:53:27 omarchy systemd[1]: Starting Bluetooth management mechanism...
Sep 05 21:53:27 omarchy systemd[1]: Started Bluetooth management mechanism.
Sep 05 21:53:32 omarchy bluetoothd[878]: profiles/audio/avdtp.c:avdtp_connect_cb() connect to 80:C3:BA:B8:06:72: Host is down (112)
Sep 05 21:53:34 omarchy bluetoothd[878]: profiles/deviceinfo/deviceinfo.c:read_pnpid_cb() Error reading PNP_ID: Invalid pdu length received
Sep 05 21:53:44 omarchy bluetoothd[878]: Device is already marked as connected
Sep 05 21:53:44 omarchy bluetoothd[878]: profiles/audio/a2dp.c:load_remote_sep() Unable to load LastUsed: rseid 8 not found
Sep 05 21:53:52 omarchy bluetoothd[878]: No matching connection for device
Sep 05 21:53:54 omarchy bluetoothd[878]: profiles/audio/a2dp.c:load_remote_sep() Unable to load LastUsed: rseid 8 not found
Sep 05 21:54:12 omarchy bluetoothd[878]: Endpoint unregistered: sender=:1.441 path=/MediaEndpoint/A2DPSink/aptx_hd
[... full endpoint unregister/reregister cycle, sender :1.441 -> :1.470 ...]
Sep 05 21:54:15 omarchy bluetoothd[878]: profiles/audio/a2dp.c:load_remote_sep() Unable to load LastUsed: rseid 8 not found
```

Card state captured immediately after, while Spotify was actively playing:

```
Card #167
        Name: bluez_card.80_C3_BA_B8_06_72
        ...
        api.bluez5.connection = "connected"
        bluez5.profile = "off"
        bluez5.auto-connect = "[ a2dp_sink a2dp_source ]"
        ...
        Profiles:
                a2dp-sink: High Fidelity Playback (A2DP Sink, codec aptX HD) (sinks: 1, sources: 0, priority: 133, available: yes)
        Active Profile: a2dp-sink
```

Sink state at the same time:

```
Sink #81
        State: SUSPENDED
        Name: bluez_output.80_C3_BA_B8_06_72.1
        Description: SM5 Press
```

## Workaround found

The only thing that reliably restored working audio:

```
bluetoothctl remove 80:C3:BA:B8:06:72
# put headset back into pairing mode
bluetoothctl
pair 80:C3:BA:B8:06:72
trust 80:C3:BA:B8:06:72
connect 80:C3:BA:B8:06:72
exit
systemctl --user restart wireplumber
```

Note that even after a successful fresh pairing, `wpctl status` showed *no* `bluez5` device at all until `wireplumber` was restarted a second time — WirePlumber did not pick up the newly re-paired device on its own.

## Possibly related upstream issue

This looks closely related to [pipewire#502 — "Unhandled dbus signals on bluez service in bluez5 plugin"](https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/502), which describes A2DP endpoints failing to re-register cleanly when BlueZ's D-Bus interfaces are removed/changed (originally reported in the context of hibernate/resume). The endpoint sender-ID churn observed here (`:1.387` → `:1.396` → `:1.418` → `:1.441` → `:1.470`, one new sender per reconnect) looks like the same class of failure, just triggered by ordinary reconnects rather than hibernation specifically.

## Additional notes

- `api.bluez5.codec` correctly reports `aptx_hd` throughout, so codec negotiation itself is not at fault.
- The bug reproduces regardless of whether the reconnect is user-initiated (UI toggle, physical headset power button) or software-initiated (service restart), suggesting the issue is in how WirePlumber/BlueZ handle *any* teardown-and-reestablish of the A2DP transport, not one specific trigger.