-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth Headset JBL LIVE 650 BT NC reconnects as handsfree only #3347
Comments
I have this exact same issue. PopOS 22.04, same info from The same headphones work as expected on Ubuntu 20.04. Also worth noting, the same headphones have worked fine with PopOS 22.04 until relatively recently. There must have been an update that broke them. I posted about this on an older issue I found as well: #2740 (comment). Looks like others are experiencing the same issue. Judging by the date of that comment (8/9/2024) and of this issue (8/8/2024), I'd guess the issue was introduced sometime in July? As of my above comment I had already been experiencing it for a few weeks, I'd estimate. A super-frustrating issue! |
Okay, I actually did some digging on the pipewire issue tracker and found some really helpful info! The above comment was made by someone who has confirmed that, for them at least, downgrading from kernel version Following is on my machine:
According to my dpkg logs, this kernel version was installed on my machine on June 20, 2024. The timing lines up! Now, I guess I have two questions left:
P.S. Someone mentioned this alternate workaround, but not sure if it's the same issue we're experiencing:
I doubt the headphone config software runs on Linux, so I probably can't test it out... |
I experience a similar situation (see #2740 (comment)). Nice find for the issue. I added a long comments with lots of logs on my end on their GitLab. Maybe your syslog outputs something similar to mine? (connection refused) |
Similar, but not quite the same... this is the only (seemingly) relevant thing I in my
|
By the way, I was able to confirm that downgrading the kernel solves the issue, at least for me. Couple different options for this:
Option 2 makes me a little nervous because I don't know whether that default is updated if/when there's another kernel update. Knowing me, I'd forget about it and realize years later that I was still on an old kernel 😅 Haven't heard back from Sys76 support yet so don't know what the official recommendation is. |
Don't want to duplicate too much info across all these threads, but this bit of info might be relevant to the PopOS folks if/when they see this:
|
Heard back from System76 support! Here's what they say:
No idea when the above would be merged/released, but at least there's a workaround in the meantime! |
Thanks for the replies everyone and for confirming I am not the only one with this issue! Now personally I am not willing to mess with my OS kernel at this time, so I'll be dealing with this issue until a new kernel will eventually fix thie issue. |
I have the same problem with ubuntu 24.04 kernel 6.8.0-47-generic. So I guess the problem goes deeper on this matter. |
In my case, with the latest Stable, it gets un-confused by using Blueman to force it back into the right modes. Something's off in the method that System76 is using with the controls there. Even if it gets muddled with Ubuntu's stuff there, there's something within Blueman that works RIGHT in the first place against the bevy of other people's (Ubuntu, Pop!_OS...you get the point), "my way," on these things (Not bagging on System76 here...except for the counterintuitve route to get to the config there, it's CLEANER overall than most...it's just not working right...sigh...) the ultimate answer is that Blueman manages to let you tell it, "No, stupid...go into THIS mode..." correctly- even if the thing still gear switches wrongly. That's a hint. If it would let you grab the reins easily and tell it which mode you want it bloody in, it'd be just shy of perfection- it doesn't. And that's what is broken here and we probably ought to merge the two or more tickets into ONE there and focus on probably making it be that way even if it doesn't pick modes transparently right. |
Yesterday I switched my computer over to Fedora Linux with KDE desktop. Fedora Linux always has a very up-to-date kernel version and the issue is fixed in the kernel version that I'm running on Fedora which is 6.12.6-200. I will likely stay with Fedora because of the faster updates and fixes. For me it's unacceptable to have my PC in a state for months were a bug is known yet is not corrected. |
Distribution (run
cat /etc/os-release
):Related Application and/or Package Version (run
apt policy $PACKAGE NAME
):Issue/Bug Description:
My JBL LIVE 650 BT NC Bluetooth headphone always will only reconnect as "handsfree" after it has been connected to my PC once. After the headphones have been successfully connected once, all further attempts to reconnect the headphones to my computer, the "headset" option will disappear entirely and I need to forget the device from Bluetooth settings and pair it again to my computer in order to get the headset option to appear again, every time this is done, it will also connect to the headset option automatically again.
Steps to reproduce (if you know):
Enable Bluetooth on PC. Power on the Bluetooth headphones and wait for it to enter pairing mode. Select the Bluetooth headset on the PC to make it connect. In sound settings, notice that the headphones are connected using the "headset" option. Power off the headphones, and power them back on. Let the headphones automatically reconnect. Notice that now, they will reconnect as "handsfree" no matter how many times the headset is power cycled.
Expected behavior:
The Bluetooth headphones connect to my PC every time with the headset option automatically.
Other Notes:
Tested JBL Tour Pro 2 wireless earbuds and JBL Extreme 2 speakers and both connect automatically as a headset rather than handsfree. The system is using an ASUS ROG STRIX X570-E GAMING WIFI II motherboard with built-in WiFi and Bluetooth chipset.
The text was updated successfully, but these errors were encountered: