After I installed the latest update the blutetooth became broken – after a connecting to the device (headphones) and waiting a few seconds, it just disconnects itself. I believe the GIF below presents the best what’s actually going on there (blueman 's devices window):
As you can see, the bluetooth iself drops the link quality from 100% to 10% (and my headphones are next to the Pi once I’ll connected to them – so I suppose that’s not the issue with the signal). After a short time, it disconnects. I have no visual information what failed through (there’s no dialog window with error message that could pop-up).
Just to inform this doesn’t occur when my headphones are in use – eg. I’m listening music.
reinstalling linux kernel and it’s headers (it fixed my issues with the bluetooth earlier),
reinstalling all packages assotiated with the bluez (i.e bluez, bluez-utils and bluez-libs),
installing the pi-bluetooth – it had the same issue + I had a choppy audio that weren’t an issue earlier (I believe it were also updated from the version 1.2 to 1.3 – so it is incompatible with the RPi4 right now; I’m not sure about that, through),
reinstalling/installing back the brcm-patchram-plus package – no effects at all.
making sure that the pi-bluetooth/brcm-patchram-plus services are running – they were.
Has anyone got an idea why this could happen? Am I the only person affected with this issue?
BTW I’ve never an issue with the bluetooth connection earlier (sometimes the adapter weren’t visible after an update, but reinstalling the kernel seemed to fix that).
Nothing changed with the pi-bluetooth package except removing a dependency to an unrelated bluetooth package so we could move to another package away from pi-bluetooth because of choppy blutooth audio. I am surprised you did not have choppy audio with the pi-bluetooth package installed.
We had posted about this in a few threads on how to move to the new bluetooth package with this last stable and testing updates but it was a temporary fix doing things manually.
@Strit pushed a while ago to the unstable branch a totally new package that will find and load the correct bluetooth firmware for all pi boards automatically at boot. Switch to the unstable branch and look for this package and version when the mirrors sync and install it: brcm-patchram-plus-r3.bee0942-3
Since you probably installed the old pi3-bluetooth you will have to do this to force installing the new package and remove pi-bluetooth:
Yea, that’s what I did right now and earlier – it seems not work for me through. And the service is/were enabled, too…
I’m on my way trying to downgrade to the older version (and to the pi-bluetooth package).
And that’s true, I’ve never had a sort of issue with a choppy audio – and it even were playing fine with the surround effect.
Right now, when I stop listening a music for a while, it disconnects itself. This is pretty irritating sometimes, especially for apps that needs to be relaunched to update their sound device.
Nothing changed with the pi-bluetooth package loading the firmware. Looking like you may getting some interference with the signal level dropping or low battery.
Oh, I meant by these word I just switch to the pi-bluetooth and I’ll install the slighty older version of the brcm-patchram-plus.
Also, I’m pretty sure this isn’t affected with the hardware – this behaviour never happened to me before with the older bluetooth firmware. And also my headphones won’t disconnect as long as I’m listening music or any app emits the sound – they disconnect only when my OS don’t send any sound data to my headphones.
Also worth noticing, there’s probably the same delay before my headphones disconnects – it is close to the 30 secs, but I’m gonna analyse the video (that I made before I’ve converted it to the GIF) once again to make it sure. Is there maybe any setting that potentially control that?
I am out of ideas. I have tested this on the pi3, pi3b+, pi4 and pi400. I just tested again and have gone through Journey’s Don’t Stop Believ’n song 4 times and no issue. I am 6’ away from the pi 4 and it is blocked by my monitor.
This actually occurs when I’m not listening music.
When I’m listening music, watching a videos with the sound or running the application that produces the sound, my headphones won’t disconnect.
I watched a little of a movie and still no issue. One thing I am sure of is the command line for the pi4 in brcm-patchram-plus has not changed since the package was pushed to the repo over a year ago. @Strit added to the package some conditions to check the board so it could load the right firmware for other boards. If the wrong firmware was trying to load you would not any bluetooth.
Since you have no issue with music but movies and web then it sounds like to me a DE or config issue possibly associated with the upgrade if it worked with before the upgrade.
I meant that as long as my headphones are in active state (when listening music etc.) it will stay connected. But after my headphones switched to the idle state, it disconnects after some time. So it also stays connected while I’m watching a videos or doing any such stuff that produces the sound.
@Strit actually it gave me an idea to switch something else and it seems it makes the time since the disconnection a little longer than it were before…
I’ve disabled the “PowerManager” add-on in the blueman-manager and it seems it stays now a little longer than before – around 2-3 minutes… So this might be partially associated with that, but IDK how…
Anyway, this is great improvement from “a few seconds”. Thanks for your answer!
Just to make it clear, I’m using exactly Bluedio T5S headphones.
Ok, I can confirm this also happens for me while connecting to the other devices… I’ve tried with the smartphone and it keeps disconnecting, but unlike my headphones it also reconnects once it has disconnected…
Ok, I think I might fixed it… At least, it doesn’t disconnect right now…
I’ve found on the web that changing the pulseaudio configuration might help by itself – so I’ve tweaked it a bit… and I’ve found these two ways that seems to make this issue a little less irritating for me:
disabling the module (exactly: load-module module-suspend-on-idle) that brings sink sources to the idle state – I would call that rather a work-around, but right now this is the only way that would guarantee me 100% active connection without auto disconnection; on the other hand, my headphones won’t go idle – and it won’t save the battery for later.
changing the discovery-bluetooth-module to discovery-bluez5-module – this looks promising right now – my headphones are over 10min idle and they haven’t disconnected. nope, that’s probably not still what I wanted, because they still disconnects… However it might made my connection actually more stable than it were before, but can’t confirm that for sure.
Right now the longest time it stayed idle without disconecting were like 15 minutes… This is near of my acceptable time, but I’m not so enthusiastic about that – my bluetooth connection quality changes each time I reconnect my headphones – and this sort of randomness is just something I am most afraid of.
The most annoying is fact that I still have this journalctl error each time my headphones disconnects by themselves:
Just to inform this occurs also after I reflashed the entire OS…
Any ideas why? Am I the only one with such problem?
I’m gonna repeat myself, because you @Darksky, you’ve tested your BT headset when it was active – but all of my media devices (smartphone emits sound through the bluetooth when connected) seems to disconnect only after they went to the idle state (this is visible when the icons in the blueman flashes slower than they normally would)…
Sorry I haven’t specified that cleanly. Appreciate you wanted to fix that issue…
I believe you were right with that, @Darksky, that this is not caused just by the pi-bluetooth or brcm-pathram-plus package – but it weren’t the case before the newest stable update. Maybe something different changed? Like linux-firmware for an example?
I’m really stuck with this issue: I believe that disabling the load-module module-suspend-on-idle in pulseaudio will drain my battery a lot faster than normaly – so there’s no complex way for me right now.
Oh, and I’ve need to mention that this is random when it comes to the time before any of the devices disconnects after I did the modifications above… so nothing helped me at all, actually…
It seems that Strit’s anwer is helping me to gain a longer time with no disconnection, but this doesn’t have 100% success rate – my headphones might last once for 30 seconds and another time for 30 minutes…
As I never met such an issue with the linux earlier, I believe I don’t know what causes that… Maybe I should send there a little more details? Maybe some configs, like /etc/bluetooth/main.conf or /etc/pulse/default.pa?
When I disabled the (Wi-Fi) network with the NetworkManager applet, the bluetooth won’t disconnect, but it will once I re-enable it. So it seems that the on-board wireless network adapter conflicts with the bluetooth.
@Darksy, I’ve fixed this issue by installing the older firmware (exactly firmware-raspberrypi), which is present in Arch Linux repository. So it seems that the new firmware package broke the bluetooth. Maybe we should use the firmware provided by the Arch Linux Repository then? My bluetooth connection is way more stable when idle with that firmware.
BTW I’m not the only one with that issue – see this GitHub issue and this issue that describes the similar problems with the latest firmware.
@Strit just to notice you I’ve found myself the real reason why BT didn’t work.It seems the power management were fine and the real problem was that the on-board Bluetooth inteface were conflicting with the onboard Wi-Fi.
Thank you again, Manjaro devs for your interest with my issue – I’ll hope you will bring the proper fix soon into the repository. I’m still curious if you could reproduce this issue with the new details I’ve provided you. Just in case my wifi connections has the 2,4GHz frequency – and many people declared that 5GHz is not the case and it won’t interfere with the Bluetooth connection.
– I’ll hope you will bring the proper fix soon into the repository. I’m still curious if you could reproduce this issue with the new details I’ve provided you. Just in case my wifi connections has the 2,4GHz frequency – and many people declared that 5GHz is not the case and it won’t interfere with the Bluetooth connection.