-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: STICKY: Bullseye - Comments and bug reports thread.
RPI 4 (4gb), 32 bit RPI OS with the latest updates. Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds. This started to happen within the last 2 months or so after a set of updates. Still happens. It is not a big deal but it is a nuissance to wait for it to get back to responsive. Like i said it happens only once (well maybe twice, second one is usually shorter) right after a log on. Maybe a change in the boot process is to blame. I don't know.
-
- Raspberry Pi Engineer & Forum Moderator
- Posts: 6742
- Joined: Wed Aug 17, 2011 7:41 pm
- Location: Cambridge
Re: STICKY: Bullseye - Comments and bug reports thread.
If you have a spare sdcard, then testing whether a clean sdcard install has the issue would be useful.twilightened wrote: ↑Thu Jun 08, 2023 1:13 pmRPI 4 (4gb), 32 bit RPI OS with the latest updates. Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds. This started to happen within the last 2 months or so after a set of updates. Still happens. It is not a big deal but it is a nuissance to wait for it to get back to responsive. Like i said it happens only once (well maybe twice, second one is usually shorter) right after a log on. Maybe a change in the boot process is to blame. I don't know.
If it doesn't then allow the normal apt updates - does it do it then?
-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: STICKY: Bullseye - Comments and bug reports thread.
I think i have found the issue:dom wrote: ↑Thu Jun 08, 2023 2:19 pmIf you have a spare sdcard, then testing whether a clean sdcard install has the issue would be useful.twilightened wrote: ↑Thu Jun 08, 2023 1:13 pmRPI 4 (4gb), 32 bit RPI OS with the latest updates. Desktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds. This started to happen within the last 2 months or so after a set of updates. Still happens. It is not a big deal but it is a nuissance to wait for it to get back to responsive. Like i said it happens only once (well maybe twice, second one is usually shorter) right after a log on. Maybe a change in the boot process is to blame. I don't know.
If it doesn't then allow the normal apt updates - does it do it then?
Run 1
prepare-file;0;0;5039;9
seq-write;0;0;7797;15
rand-4k-write;0;0;2620;655
rand-4k-read;11391;2847;0;0
Sequential write speed 7797 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 655 IOPS (target 500) - PASS
Random read speed 2847 IOPS (target 1500) - PASS
Run 2
prepare-file;0;0;6142;11
seq-write;0;0;6038;11
rand-4k-write;0;0;2088;522
rand-4k-read;11090;2772;0;0
Sequential write speed 6038 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 522 IOPS (target 500) - PASS
Random read speed 2772 IOPS (target 1500) - PASS
Run 3
prepare-file;0;0;6115;11
seq-write;0;0;6066;11
rand-4k-write;0;0;2039;509
rand-4k-read;11047;2761;0;0
Sequential write speed 6066 KB/sec (target 10000) - FAIL
Note that sequential write speed declines over time as a card is used - your card may require reformatting
Random write speed 509 IOPS (target 500) - PASS
Random read speed 2761 IOPS (target 1500) - PASS
Test FAIL
Re: STICKY: Bullseye - Comments and bug reports thread.
twilightened wrote: ↑Thu Jun 08, 2023 1:13 pmDesktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds.
It seems unlikely to me that the SD Card not being quite as fast as might be desirable is the cause of the Pi going unresponsive for so long. I have used Pi with far slower cards than that and haven't observed any problems seemingly caused by doing so. In fact I have only recently used cards which don't fail the tests.twilightened wrote: ↑Thu Jun 08, 2023 7:28 pmI think i have found the issue:
Sequential write speed 7797 KB/sec (target 10000) - FAIL
If it were a card speed issue then all a faster card would do is reduce the period of unresponsiveness. You aren't too far off the targets so would seem to be needing a card many times faster than the target to reduce that period to almost nothing, which doesn't seem plausible.
That said my Pi 3B does, more regularly than I'd like, go unresponsive for 15 seconds or so at a time. Never figured out why, and that's 32-bit Buster, so, if it is a systemic issue, it pre-dates Bullseye.
-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: STICKY: Bullseye - Comments and bug reports thread.
I had my own doubts about that so thanks for the support. I am living with it. Not a big issue to be honest. In the end, RPI is not the fastest computer anyway. So it is ok to wait for some time for it to come back alive. I am an old and slow guy myselfhippy wrote: ↑Sat Jun 10, 2023 4:49 pmtwilightened wrote: ↑Thu Jun 08, 2023 1:13 pmDesktop stops responding after a short while right after a boot. It is momentarily, lasts around 20 seconds.It seems unlikely to me that the SD Card not being quite as fast as might be desirable is the cause of the Pi going unresponsive for so long. I have used Pi with far slower cards than that and haven't observed any problems seemingly caused by doing so. In fact I have only recently used cards which don't fail the tests.twilightened wrote: ↑Thu Jun 08, 2023 7:28 pmI think i have found the issue:
Sequential write speed 7797 KB/sec (target 10000) - FAIL
If it were a card speed issue then all a faster card would do is reduce the period of unresponsiveness. You aren't too far off the targets so would seem to be needing a card many times faster than the target to reduce that period to almost nothing, which doesn't seem plausible.
That said my Pi 3B does, more regularly than I'd like, go unresponsive for 15 seconds or so at a time. Never figured out why, and that's 32-bit Buster, so, if it is a systemic issue, it pre-dates Bullseye.

-
- Posts: 633
- Joined: Wed Jun 20, 2018 12:38 am
Re: STICKY: Bullseye - Comments and bug reports thread.
I've noticed that I can rerun failed sd card speed tests just a few minutes later, and get wildly better results. I have many pi models and many makes/models/sizes/vintages of cards, and I haven't fully investigated this. The particular examples below are from a 2B and a Samsung Evo+ 32GB card. The random and sequential writes are the ones that change so much. Could some mysterious process running or writing during the first try explain the slowness? It's hard to believe that the performance of the card itself is that variable...
Here's one example (slow first), the results of a script of mine giving hostname, pi details, sd card details, hdparm test results reformatted to look like sdtest results (with an arbitrary norm of 20MB/sec), and then the usual sd card test stuff:
Now, the faster version (same pi, same card):
Here's one example (slow first), the results of a script of mine giving hostname, pi details, sd card details, hdparm test results reformatted to look like sdtest results (with an arbitrary norm of 20MB/sec), and then the usual sd card test stuff:
Code: Select all
pi2
2B 1.1 1GB
Samsung Evo+ U1 32 82
buffered disk reads: 31.26 MB/sec (target 20.00) - PASS 156%
Random read speed 2981 IOPS (target 1500) - PASS 198%
Random write speed 413 IOPS (target 500) - FAIL 82%
Sequential write speed 19015 KB/sec (target 10000) - PASS 190%
Code: Select all
pi2
2B 1.1 1GB
Samsung Evo+ U1 32 82
buffered disk reads: 31.23 MB/sec (target 20.00) - PASS 156%
Random read speed 3061 IOPS (target 1500) - PASS 204%
Random write speed 917 IOPS (target 500) - PASS 183%
Sequential write speed 21140 KB/sec (target 10000) - PASS 211%
-
- Posts: 633
- Joined: Wed Jun 20, 2018 12:38 am
Re: STICKY: Bullseye - Comments and bug reports thread.
Here's the same situation - widely different speed test results, in particular the writes, this time on a Zero W, with a SanDisk card. And, yes, both the 2B and the ZeroW are bullseye, 32-bit.
Code: Select all
pi0w5
Zero W 1.1 512MB
SanDisk Ultra PLUS U1 16 93
buffered disk reads: 22.11 MB/sec (target 20.00) - PASS 110%
Random read speed 1748 IOPS (target 1500) - PASS 116%
Random write speed 611 IOPS (target 500) - PASS 122%
Sequential write speed 7059 KB/sec (target 10000) - FAIL 70%
Code: Select all
pi0w5
Zero W 1.1 512MB
SanDisk Ultra PLUS U1 16 93
buffered disk reads: 21.90 MB/sec (target 20.00) - PASS 109%
Random read speed 1754 IOPS (target 1500) - PASS 116%
Random write speed 790 IOPS (target 500) - PASS 158%
Sequential write speed 13557 KB/sec (target 10000) - PASS 135%
-
- Posts: 1582
- Joined: Fri Jan 04, 2013 1:57 pm
- Location: de_DE
Re: STICKY: Bullseye - Comments and bug reports thread.
i guess the differences in speed comes from the different tasks running in the background.
{ I only give negative feedback }
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)
RPi B (256MB), B (512MB), B+, ZeroW; 2B; 3B, 3B+; 4B (4GB)
Re: STICKY: Bullseye - Comments and bug reports thread.
Could also be the cpu frequency governor, by default it is in ondemand mode which varies frequency considerably depending on load.
-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: STICKY: Bullseye - Comments and bug reports thread.
I don't remember seeing any updates for the last two weeks or so. Is that normal? sudo apt update says everything is up to date. It has been saying that for a long time now.
Re: STICKY: Bullseye - Comments and bug reports thread.
Quite normal, happens for a while every now and again.
That and Bookworm is the new Debian, so all Debian work goes there and I guess RPiOS will be too. (no RPiOS version of it though, yet...)
That and Bookworm is the new Debian, so all Debian work goes there and I guess RPiOS will be too. (no RPiOS version of it though, yet...)
Re: Screen Blanking iussue (again and solved)
I refer to the problem previously mentioned here 2 months ago.
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!
The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H
- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working
For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.
So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!

The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H
- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working
For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.
So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!
-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: Screen Blanking iussue (again and solved)
swap hdmi cables and try. it might be the culprit.JumpZero wrote: ↑Mon Jun 26, 2023 4:20 pmI refer to the problem previously mentioned here 2 months ago.
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!
The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H
- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working
For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.
So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!
Re: Screen Blanking iussue (again and solved)
Good point! Tested today but no the cable isn't the culprit. Screen blanking isn't working only when the HP2311x monitor is alone on HDMI1. In all other configurations (S24D340H alone, S24D340H + HP2311x in HDMI1 or 2) screen blanking works.twilightened wrote: ↑Tue Jun 27, 2023 3:57 pmswap hdmi cables and try. it might be the culprit.JumpZero wrote: ↑Mon Jun 26, 2023 4:20 pmI refer to the problem previously mentioned here 2 months ago.
So it seems my screen blanking issue is solved, but anyway it is strange:
Today I added a second monitor to my pi400 and the screen blanking started to work as expected!
The config is the following:
HDMI1 = HP2311x
HDMI2 = Samsung S24D340H
- with both screens and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = Samsung S24D340H and vc4-kms-v3d enabled in config.txt screen blanking is working
- with only 1 screen (HDMI1) = HP2311x and vc4-kms-v3d enabled in config.txt screen blanking is NOT working
For this later configuration, as previously mentioned, I must revert from vc4-kms-v3d to vc4-fkms-v3d to have screen blanking working.
So I conclude that the problem is with this HP2311x screen. Does it meet the full HDMI specs?...
As already said the screen goes blanking but just for a few seconds. I wonder what event causes it to wake up. Xevent didn't find anything.
Ok not a big deal!
-
- Posts: 7
- Joined: Thu Jul 06, 2023 9:33 am
Re: STICKY: Bullseye - Comments and bug reports thread.
BUGS REPORT
It is not possible to log-in to desktop via realvnc ii wayland is enabled, because login prompt can't be removed, and if login promt appear desktop can't be entered via realvnc no matter with or without wayland.
So from there we have 2 issues:
1. Can't log-in to desktop vie vnc if user is not already logged-in. If user is auto logged-in and log-out it can't log-in again via realvnc connection
2. If wayland is enabled desktop auto log-in doesn't work and as a result desktop can't be accessed via realvnc
Next issue is with RDP
User root and default user can't log-in via RDP. If new user is created it can log-in but can't do anything because there are no groups assigned to it. Because sudo group is most important I assign at first sudo group and it can log-in and perform sudo command but user is limited and for example can't see camera window. If I add some other group to the new user in addition to sudo user can't log-in via RDP
Chrome browser have super lag if user is logged-in via realvnc and is completely useless. In same conditions firefox is responsive. There is no such issue if user is logged via RDP
It is not possible to log-in to desktop via realvnc ii wayland is enabled, because login prompt can't be removed, and if login promt appear desktop can't be entered via realvnc no matter with or without wayland.
So from there we have 2 issues:
1. Can't log-in to desktop vie vnc if user is not already logged-in. If user is auto logged-in and log-out it can't log-in again via realvnc connection
2. If wayland is enabled desktop auto log-in doesn't work and as a result desktop can't be accessed via realvnc
Next issue is with RDP
User root and default user can't log-in via RDP. If new user is created it can log-in but can't do anything because there are no groups assigned to it. Because sudo group is most important I assign at first sudo group and it can log-in and perform sudo command but user is limited and for example can't see camera window. If I add some other group to the new user in addition to sudo user can't log-in via RDP
Chrome browser have super lag if user is logged-in via realvnc and is completely useless. In same conditions firefox is responsive. There is no such issue if user is logged via RDP
Re: STICKY: Bullseye - Comments and bug reports thread.
I have this problem, the Ubuntu 22.04 on 7600X CPU runs Wayland.bensimmo wrote: ↑Sat Jul 08, 2023 9:45 amWayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-
Use something else.
I had disabled Wayland by the method you pointed to, and just did it again.
After that Ubuntu "Settings" does show X11 and not Wayland.
And gimp is able to take screenshots, only black with Wayland:
The question I have is, which pair of vnc client(64bit PiOS) and vnc server(Ubuntu) does work?
I tried xtightvncclient/xtightvncserver and see grey empty screen only...
I really would like to get rid of 2nd keyboard and mouse I have to use currently:
viewtopic.php?p=2116569#p2116569
https://github.com/Hermann-SW/RSA_numbers_factored
https://stamm-wilbrandt.de/GS_cam_1152x192@304fps
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/
https://stamm-wilbrandt.de/GS_cam_1152x192@304fps
https://hermann-sw.github.io/planar_graph_playground
https://github.com/Hermann-SW/Raspberry_v1_camera_global_external_shutter
https://stamm-wilbrandt.de/
-
- Posts: 7
- Joined: Thu Jul 06, 2023 9:33 am
Re: STICKY: Bullseye - Comments and bug reports thread.
This link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.bensimmo wrote: ↑Sat Jul 08, 2023 9:45 amWayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-
Use something else.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad
Re: STICKY: Bullseye - Comments and bug reports thread.
Regardless of what you consider to be your problem, you are using wayland and RealVNC is not compatible with waylaid,. Fix that problem and maybe a miracle will happen and all your problems may go away.easy-and-simple wrote: ↑Sat Jul 08, 2023 10:55 amThis link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.bensimmo wrote: ↑Sat Jul 08, 2023 9:45 amWayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-
Use something else.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad
I fail to follow your logic that you should continue to use something that is known not to work. "use something else" appears to be the most logical answer.
Re: STICKY: Bullseye - Comments and bug reports thread.
I did read, I was just replying to the Wayland issue only. Maybe this one is bettereasy-and-simple wrote: ↑Sat Jul 08, 2023 10:55 amThis link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.bensimmo wrote: ↑Sat Jul 08, 2023 9:45 amWayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-
Use something else.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad
https://help.realvnc.com/hc/en-us/artic ... g-on-Linux
Not the general issue if Wayland is not used and you still cannot log in.
I'm sure others will be able to help with your problem where Wayland is disabled.
But RealVNC have a support section, use them too.

-
- Posts: 7
- Joined: Thu Jul 06, 2023 9:33 am
Re: STICKY: Bullseye - Comments and bug reports thread.
No this is not the issue, because wayland doesn't cause video problems. Problem is caused obviously by vnc server itself, because it can't log-in user to desktop. On other side there is problem with raspi-config because it cant set desktop auto log-in then wayland is enabledbensimmo wrote: ↑Sat Jul 08, 2023 1:12 pmI did read, I was just replying to the Wayland issue only. Maybe this one is bettereasy-and-simple wrote: ↑Sat Jul 08, 2023 10:55 amThis link is for other issue. I don;t have blank screen. I see desktop, but VNC server can't log me in after I enter password.Also black screen is not caused by wayland. I am sure because I had this issue while I tried to find solution for my issue.bensimmo wrote: ↑Sat Jul 08, 2023 9:45 amWayland
https://help.realvnc.com/hc/en-us/artic ... C-Connect-
Use something else.
You didn't read what is the broblem. Problem is in unsuccessful login not in wayland. Read more carefully
Your logic "use something else" is bad
https://help.realvnc.com/hc/en-us/artic ... g-on-Linux
Not the general issue if Wayland is not used and you still cannot log in.
I'm sure others will be able to help with your problem where Wayland is disabled.
But RealVNC have a support section, use them too.![]()
Re: STICKY: Bullseye - Comments and bug reports thread.
Of course it is RealVNC, it just doesn't work with Wayland. RealVNC tell you that. I linked to a page telling you that.
You can try all you like to use Wayland.
You cannot use Wayland with RealVNC, until RealVNC fix it.
To find out more, ask them, they may have a fix in testing.
Perhaps there is something missing in yours and my descriptions to each other.
Auto-login with no Wayland is a different issue.
So disable Wayland, tell us your Pi/Computer setup in a new thread/topic post and people can help.
----
This is as far as I've got..
We are assuming you have PiOS installed on a RaspberryPi of some sort and you have enabled RealVNC and the 'in testing, not recommend for use Wayland option'.
You are then connecting from another computer
We know Wayland will not work with the VNC setup, so that needs to go.
You then say there is still a problem.
When you log over VNC it doesn't auto log in.?
Post about that in a new Topic.
You can try all you like to use Wayland.
You cannot use Wayland with RealVNC, until RealVNC fix it.
To find out more, ask them, they may have a fix in testing.
Perhaps there is something missing in yours and my descriptions to each other.
Auto-login with no Wayland is a different issue.
So disable Wayland, tell us your Pi/Computer setup in a new thread/topic post and people can help.
----
This is as far as I've got..
We are assuming you have PiOS installed on a RaspberryPi of some sort and you have enabled RealVNC and the 'in testing, not recommend for use Wayland option'.
You are then connecting from another computer
We know Wayland will not work with the VNC setup, so that needs to go.
You then say there is still a problem.
When you log over VNC it doesn't auto log in.?
Post about that in a new Topic.
-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: STICKY: Bullseye - Comments and bug reports thread.
I used to have problems with my bluetooth earbuds connecting to my RPI4. Everytime i wanted to connect, i was forced to "remove" the device and then repair it. Connection without repairing wouldn't work.
Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.
Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?
Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.
Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?
Re: STICKY: Bullseye - Comments and bug reports thread.
I have no problem with my cheap Onn BT earbuds.twilightened wrote: ↑Wed Jul 12, 2023 10:57 amI used to have problems with my bluetooth earbuds connecting to my RPI4. Everytime i wanted to connect, i was forced to "remove" the device and then repair it. Connection without repairing wouldn't work.
Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.
Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?
Make sure that the earbud is not connecting to another BT device such as a phone. If so turn off BT on the phone before attempting to connect with the RPi.
Unless specified otherwise my response is based on the latest and fully updated RPi OS Bullseye w/ Desktop OS.
-
- Posts: 245
- Joined: Fri Sep 03, 2021 12:31 am
Re: STICKY: Bullseye - Comments and bug reports thread.
I used to have a pair of Lenovos. Every time i had to re-pair them (remove them from the bluetooth memory and then reconnect). They are gone now and i have a pair of Omthing Airfree earbuds (they are pretty decent). It is pretty much the same story. Sometimes when i take them out of the box, i again have to re-pair them (remove first and pair after) just to have them connected as an audio target. Otherwise if i select them as audio output, i get a connection error.klricks wrote: ↑Wed Jul 12, 2023 3:50 pmI have no problem with my cheap Onn BT earbuds.twilightened wrote: ↑Wed Jul 12, 2023 10:57 amI used to have problems with my bluetooth earbuds connecting to my RPI4. Everytime i wanted to connect, i was forced to "remove" the device and then repair it. Connection without repairing wouldn't work.
Now that i have a second (and different) pair of BT earbuds, i thought it would be different, but it is exactly the same.
Why am i having these connection issues with BT earbuds in RPI? Is this normal? Are everybodys' experience the same when it comes to BT audio connections?
Make sure that the earbud is not connecting to another BT device such as a phone. If so turn off BT on the phone before attempting to connect with the RPi.
However, i also have a bluetooth speaker and it just connects instantly. I had no issues whatsoever. So i guess it has a far better BT chip inside. I am unlucky with my BT earbuds.
"Failed to connect, resource temporarily unavailable". This is the error i get when i try to select my BT earbuds as audio output. In that case, what i have to do is to "remove" BT earbuds from paired devices. Then search for BT devices and re-pair them. Only after that i can select them as output.
So why does this happen?