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.

Version 25.12.2 (February 5) on arch-arm has fixed the issue for me. Before that, i was using a "built from source" installation and it already had the fix, so i waited for the official package manager (pacman) to sync. Arch is quite fast with the updates.

So, if you are on a cutting edge distro (like ARCH), you probably already have the fix. If you are on a "stable" release, i suggest, if you can do it, remove the kdeconnect installed by your own package manager, then build from source like me and install that. You can learn how to do this via a LLM (like chatgpt). Provide your system information, provide the following link and ask chatgpt how to build and install this package from source:

https://invent.kde.org/network/kdeconnect-kde

Seems to be fixed in Fedora 43 (AMD 5700x desktop, UE Wonderboom bluetooth speaker) after updating KDE connect to 25.12.2. Removing the kde-connect package also fixed the issue.

For me the bug is still there with 25.12.2

I am also experiencing this still in 25.12.2. Fresh install of CachyOS (arch based) with KDE Plasma.
Audio plays fine for 10 sec at most, most of the time it's a garbled mess. As soon as I type "pkill kdeconnect" in the terminal the issue is instantly gone.

(In reply to danilo.cvijetic10 from comment #13)
> 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.
I am using Asahi ALARM on an M1 Macbook air and I can also confirm this issue on my end, in fact it completely cuts my internet connection and makes bluetooth audio stutter until i retoggle and untoggle the bluetooth option in kdeconnect every time i boot my machine
kdeconnect 25.12.2 still has this issue

(In reply to philo from comment #24)
> (In reply to danilo.cvijetic10 from comment #13)
> > 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.
> I am using Asahi ALARM on an M1 Macbook air and I can also confirm this
> issue on my end, in fact it completely cuts my internet connection and makes
> bluetooth audio stutter until i retoggle and untoggle the bluetooth option
> in kdeconnect every time i boot my machine
> kdeconnect 25.12.2 still has this issue

There is a bug report related to the need to retoggle and untoggle the bluetooth option: https://bugs.kde.org/show_bug.cgi?id=516170. I'm not sure if it's related to this issue.

Created attachment 190473 [details]
audio packet size vs kdeconnectd inquiry events

I confirm on MacBookPro15,1 (Intel Mac), Fedora 43. I noticed via btmon that every 10s four times a minute, kdeconnectd, through the bluez dbus interface, fires a Bluetooth inquiry start/restart. The remaining 20s per minute, there is no audio stuttering. 
btmon shows that the size (dlen) of audio packets nosedives while an inquiry is in progress: see attached image.

Claude AI was used to parse btmon and generate the graph, however the analysis is mine.

Kubuntu 26.04 too. 
KDE Connect 25.12.3
Fix by disabling bluetooth backend in settings.

(In reply to cipricus from comment #27)
> Kubuntu 26.04 too. 
> KDE Connect 25.12.3
> Fix by disabling bluetooth backend in settings.

on a MacbookPro 11

(In reply to cipricus from comment #27)
> Kubuntu 26.04 too. 
> KDE Connect 25.12.3
> Fix by disabling bluetooth backend in settings.

disabling a feature is not a fix

(In reply to Roberto from comment #29)
> (In reply to cipricus from comment #27)
> > Kubuntu 26.04 too. 
> > KDE Connect 25.12.3
> > Fix by disabling bluetooth backend in settings.
> 
> disabling a feature is not a fix

Sorry, bad choice of words. What I mean is that:
* although somebody mentioned this fixed in 25.12.2 (https://bugs.kde.org/show_bug.cgi?id=513536#c20), in 25.12.3 (kubuntu 26.04) the problem is still present
* disabling the bluetooth backend avoids the problem - unlike in 25.12.1 (as reported by others), where full removable or disabling of the tool is needed

This seems related to: https://bugs.kde.org/show_bug.cgi?id=516170 (Bluetooth backend is always active when kdeconnectd starts)

Running Fedora 43 Asahi on a Macbook M1, Kernel 6.18.10, KDE Connect 25.12.3

Disabling the bluetooth backend either with the checkbox or by executing

kdeconnect-cli --disable-backend BluetoothLinkProvider

Does not stop the stuttering. Only way to "fix" the audio is by killing the kdeconnectd service
It does not seem to matter if a device is actually connected or not

Wow, this one drove me crazy this afternoon. I probably put all my audio setup upside down with latency/clock tweaks and all the "choppy sound bluetooth linux" search results of the web. I even bought a new USB dongle bluetooth to troubleshot if my dongle wasn't the cause.

A big thank you to TSUKUMO Akito for sharing the workaround in the first post (disable the KDE Connect Bluetooth backend → insta fixed the issue here).

I could reproduce in: 
- Kubuntu 26.04 LTS (live ISO) 
- Debian-testing KDE Plasma  

$ kdeconnect-app -v
kdeconnect.app 25.12.3

$ plasmashell -v
plasmashell 6.6.3

$ lsusb
Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
(connecting to an audio YAS-203 Yamaha device)

Reproduced also in KDE Neon user edition (neon-user-20260423-1323.iso) and the workaround did work there too.

$ kdeconnect-app -v
kdeconnect.app 26.04.0

$ plasmashell -v
plasmashell 6.6.4

KDE Connect's bluetooth backend's "on by default" behavior might be causing more issues than its worth for the majority of KDE users. Not only did `kdeconnectd` bluetooth scanning cause audio issues on my system, but also seriously interfered with my connection to a wifi AP and degraded the throughput by an order of 10.

Judging by the bugs on this tracker surrounding this particular backend it may be worth exploring an approach where bluetooth support could be explicitly enabled, with some sort of post-installation popup for users explaining that this requires constant scanning to function (not unlike the popup for new plasma releases). Keeping this in the background is leading to system behavior that is egregiously difficult for a non-technical user to diagnose.

Additionally, the regression from 25.12.1 seemingly not respecting configuration options correctly is making this even worse for users of KDE Connect (see: https://bugs.kde.org/show_bug.cgi?id=516170, the proposed commit reversal should be looked at, as this still persists in 26.04.1).

It would not surprise me to see some distributions patch this manually and simply disable the backend by default, which would be an unfortunate outcome given that KDE wants this functionality exposed enough to not have to dig through configuration files to enable it.

A fix for the broadcom chips found in Apple Silicon devices was submitted: https://lore.kernel.org/linux-bluetooth/20260407-brcm-prio-v2-1-3f745edf49af@gmail.com/ (see also: "Bluetooth Fixes!" in https://asahilinux.org/2026/04/progress-report-7-0/ )

To my knowledge, it doesn't apply as-is to T2 macs (e.g. BCM4364), but a corresponding change might.