Bug 513536

After the recent update from 25.12.0-1 to 25.12.1-1, even when the "bluetooth" backend of the kdeconnect is disabled, it still "constantly" uses bluetooth and causes bluetooth audio to stutter. The previous update to 25.12.0-1 was also causing the same issue, but it was possible to fix it by disabling the bluetooth backend from within the settings. Now that setting is probably being ignored by the service itself. Weird.

There should be a way to disable the bluetooth backend of kdeconnect entirely.

Comment from original reporter (myself):

I can confirm the same regression in 25.12.1-1.
Disabling the Bluetooth backend (via Settings > Backends > Bluetooth unchecked, or disabled_providers=BluetoothLinkProvider in ~/.config/kdeconnect/config) no longer works.
The interference with PipeWire A2DP audio (choppy/stuttering playback on WH-1000XM4) occurs unconditionally after connecting Bluetooth headphones.

Downgrading to 25.08.2-2 completely resolves the issue (stable, no stuttering).
Temporary workaround: Manually restart kdeconnectd after connecting headphones, but this is not practical for daily use.

Affected versions: 25.12.1-1 (EndeavourOS)
Workaround: Pin kdeconnect to 25.08.2-2 with IgnorePkg in pacman.conf

Please prioritize this regression, as it makes Bluetooth audio unusable with KDE Connect running.
Thank you!

(In reply to TSUKUMO Akito from comment #2)
> Comment from original reporter (myself):
> 
> I can confirm the same regression in 25.12.1-1.
> Disabling the Bluetooth backend (via Settings > Backends > Bluetooth
> unchecked, or disabled_providers=BluetoothLinkProvider in
> ~/.config/kdeconnect/config) no longer works.
> The interference with PipeWire A2DP audio (choppy/stuttering playback on
> WH-1000XM4) occurs unconditionally after connecting Bluetooth headphones.
> 
> Downgrading to 25.08.2-2 completely resolves the issue (stable, no
> stuttering).
> Temporary workaround: Manually restart kdeconnectd after connecting
> headphones, but this is not practical for daily use.
> 
> Affected versions: 25.12.1-1 (EndeavourOS)
> Workaround: Pin kdeconnect to 25.08.2-2 with IgnorePkg in pacman.conf
> 
> Please prioritize this regression, as it makes Bluetooth audio unusable with
> KDE Connect running.
> Thank you!

I am also on EndeavourOS but i am on a RPI5 so it is the "arm" version (based on arch arm, using the same package repository). Are you also on a RPI? If that is the case, maybe our weak bluetooth chip can't handle multiple querries and streams at the same time and stalls. But kdeconnect should not "constantly" querry for bluetooth devices i would assume. I mean it must stop at some point, but as our experience proves it, it just doesn't.

Can confirm that this bug happens on Fedora Asahi Remix 43 (aarch64, Apple Silicon), using version 25.12.1. IMO, this is of major severity.

Happening to me as well, on Fedora Asahi Remix 43 with KDE Connect 25.12.1.

(In reply to ledo.kane from comment #3)
> (In reply to TSUKUMO Akito from comment #2)
> > Comment from original reporter (myself):
> > 
> > I can confirm the same regression in 25.12.1-1.
> > Disabling the Bluetooth backend (via Settings > Backends > Bluetooth
> > unchecked, or disabled_providers=BluetoothLinkProvider in
> > ~/.config/kdeconnect/config) no longer works.
> > The interference with PipeWire A2DP audio (choppy/stuttering playback on
> > WH-1000XM4) occurs unconditionally after connecting Bluetooth headphones.
> > 
> > Downgrading to 25.08.2-2 completely resolves the issue (stable, no
> > stuttering).
> > Temporary workaround: Manually restart kdeconnectd after connecting
> > headphones, but this is not practical for daily use.
> > 
> > Affected versions: 25.12.1-1 (EndeavourOS)
> > Workaround: Pin kdeconnect to 25.08.2-2 with IgnorePkg in pacman.conf
> > 
> > Please prioritize this regression, as it makes Bluetooth audio unusable with
> > KDE Connect running.
> > Thank you!
> 
> I am also on EndeavourOS but i am on a RPI5 so it is the "arm" version
> (based on arch arm, using the same package repository). Are you also on a
> RPI? If that is the case, maybe our weak bluetooth chip can't handle
> multiple querries and streams at the same time and stalls. But kdeconnect
> should not "constantly" querry for bluetooth devices i would assume. I mean
> it must stop at some point, but as our experience proves it, it just doesn't.

@ledo.kane Thanks for the info and the suggestion.

Just to clarify: I'm actually running EndeavourOS on a **MacBook Pro 2018** (Intel x86_64) with the **linux-t2** kernel (not ARM / RPi5). So the weak Bluetooth controller theory might not fully apply here, but it's still interesting that you're seeing the same symptoms on RPi5 (ARM).

For me, the issue definitely started/regressed with KDE Connect 25.12 series and is reproducible even when the Bluetooth backend is supposedly disabled (in 25.12.1). Downgrading to 25.08.3-2 or forcing a kdeconnectd restart right after connecting the headset remains the only reliable workarounds so far.

Thanks again for testing and reporting — more confirmations from different hardware help a lot.

(In reply to Lélahel Hideux from comment #4)
> Can confirm that this bug happens on Fedora Asahi Remix 43 (aarch64, Apple
> Silicon), using version 25.12.1. IMO, this is of major severity.

@Lélahel_Hideux Thank you for confirming and for marking it as major severity — I agree it's quite disruptive.

Interesting that it's also affecting Apple Silicon (Asahi Fedora). This seems to be happening across both x86_64 and aarch64 now.

(In reply to Alessandro from comment #5)
> Happening to me as well, on Fedora Asahi Remix 43 with KDE Connect 25.12.1.

@Alessandro Thanks for the additional confirmation on Fedora Asahi Remix.

Looks like the regression in 25.12 is pretty widespread. Hopefully this gets more attention from the KDE Connect maintainers soon.

Can confirm on IMac Intel i9 9600k to and also with Sony 1000XM5. very annoying as it costed me 1 Mo of discovery and installing linux all over and over

Confirmed this is happening on:
kdeconnect 25.12.1
Operating System: Fedora Linux Asahi Remix 42
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.9.3
Kernel Version: 6.16.8-400.asahi.fc42.aarch64+16k (64-bit)
Graphics Platform: Wayland
Processors: 8 × Apple Firestorm (M1 Pro), 2 × Apple Icestorm (M1 Pro)
Memory: 30.9 GiB of usable RAM
Graphics Processor 1: Apple M1 Pro
Graphics Processor 2: llvmpipe
Product Name: Apple MacBook Pro (16-inch, M1 Pro, 2021)

KDE Connect's use of Bluetooth interferes with Bluetooth Audio. In previous versions I could disable KDE Connect's use of Bluetooth with the checkbox in KDE Connect Settings. However now it seems this checkbox is ineffective.

Symptoms:
bluetoothctl --monitor
hci0 type 1 discovering on
hci0 type 1 discovering off
hci0 type 1 discovering on
hci0 type 1 discovering off
[repeats every ~10 seconds]

Bluetooth audio is cut out while bluetooth is discovering.

For me, running `killall kdeconnectd` caused the bluetooth discovery loop to stop, and bluetooth audio to resume uninterrupted.

want to add that im on cachyos. but same on fedora, ubuntu, so it is a cross platform thing

Same on Fedora 43. After uninstalling kde-connect. The issue is gone.

These packages were uninstalled: 

    Package changes:
    -0:fuse-sshfs-3.7.5-1.fc43.x86_64
    -0:kde-connect-25.12.1-1.fc43.x86_64
    -0:kde-connect-libs-25.12.1-1.fc43.x86_64
    -0:kdeconnectd-25.12.1-1.fc43.x86_64
    -0:kf6-kpeople-6.22.0-1.fc43.x86_64
    -0:libfakekey-0.3-25.fc43.x86_64
    -0:openssh-askpass-10.0p1-6.fc43.x86_64

Hi! 
Just wanted to confirm same thing happening on Arch Linux.
It also interferes with 2.4Ghz wifi when it puts bluetooth in discovery mode, causing high latency spikes and network slowdowns.
Solution is downgrading KdeConnect.

+1 also happens to me on cachyOS and killing kdeconnect in terminal fixes the issue

made a account just to bring attention to this

(In reply to Svetlana from comment #14)
> +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes
> the issue
> 
> made a account just to bring attention to this

thx for your reply. Are you having this on mac or non mac hardware too?

(In reply to Martin from comment #15)
> (In reply to Svetlana from comment #14)
> > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes
> > the issue
> > 
> > made a account just to bring attention to this
> 
> thx for your reply. Are you having this on mac or non mac hardware too?

This is on non Mac hardware (5800X3D CPU)

(In reply to Svetlana from comment #16)
> (In reply to Martin from comment #15)
> > (In reply to Svetlana from comment #14)
> > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes
> > > the issue
> > > 
> > > made a account just to bring attention to this
> > 
> > thx for your reply. Are you having this on mac or non mac hardware too?
> 
> This is on non Mac hardware (5800X3D CPU)

(In reply to Martin from comment #15)
> (In reply to Svetlana from comment #14)
> > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes
> > the issue
> > 
> > made a account just to bring attention to this
> 
> thx for your reply. Are you having this on mac or non mac hardware too?

On my side it's also happening on non mac hardware too (Ryzen 7 7840hs). Before finding out it's kdeconnect issue, I assumed it's related to wifi hardware/drivers so I swapped my MT7922 for Intel AX210 card. I can confirm same thing happening on both cards.

(In reply to danilo.cvijetic10 from comment #17)
> (In reply to Svetlana from comment #16)
> > (In reply to Martin from comment #15)
> > > (In reply to Svetlana from comment #14)
> > > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes
> > > > the issue
> > > > 
> > > > made a account just to bring attention to this
> > > 
> > > thx for your reply. Are you having this on mac or non mac hardware too?
> > 
> > This is on non Mac hardware (5800X3D CPU)
> 
> (In reply to Martin from comment #15)
> > (In reply to Svetlana from comment #14)
> > > +1 also happens to me on cachyOS and killing kdeconnect in terminal fixes
> > > the issue
> > > 
> > > made a account just to bring attention to this
> > 
> > thx for your reply. Are you having this on mac or non mac hardware too?
> 
> On my side it's also happening on non mac hardware too (Ryzen 7 7840hs).
> Before finding out it's kdeconnect issue, I assumed it's related to wifi
> hardware/drivers so I swapped my MT7922 for Intel AX210 card. I can confirm
> same thing happening on both cards.

Thats good, as if it solely had been Apple Hardware they would never make it a priority

Thanks all for contributing to this thread.

Hey, on my side (Fedora 43) this is only happening after: https://invent.kde.org/network/kdeconnect-kde/-/commit/2f62b712c7cb8415dde784621ab667a992af856f

However, it seems to me that this just uncovers the underlying issue, because the problem only occurs when device discovery is started via `QBluetoothServiceDiscoveryAgent`.

If I'm not mistaken, before this commit, `mServiceDiscoveryAgent->start()` never gets triggered, because `BluetoothLinkProvider::connectTimer` was never started, whereas afterwards `AsyncLinkProvider::connectTimer` is started right away.