Sony WH-1000XM3 Connection refused on first connect #43
Comments
|
If the device is already connected, it means there is an open socket between the laptop and the headset. This script opens a new socket and some devices don't like that and act weird. Some don't even work until you disconnect them first. The only solution for these kinds of issues that comes to my mind is to integrate the functionality of this script into the actual program that's responsible for Bluetooth connections (e.g. pulseaudio-bluetooth or something like that) so there is only one socket. I think there are some open merge requests on those projects that will eventually deprecate this one. But for now, I suggest you use this script to connect in the first place. If the device kept being connected after running the script, then that's probably good enough and won't show any errors. |
|
yes, my workaround is to always call the script twice atm, but i might look into the whole problem soon. |
|
I lost interest in this project a long time ago, but it's great seeing how many people contribute and work together to keep it moving forward. I hope you find a solution for this problem. Any pull-request is always welcome. |
|
Same headset. Since I only have this one headset I went the tried and true method of just running it again as part of the error handling Just put the connection in the error. Works 100% of the time now :) |
|
I got WH1000-XM3 to just work by adding $ bluetooth-headset-battery-level <MAC>.10
Battery level for <MAC> is 50%
$ dbus-send --print-reply=literal --system --dest=org.bluez /org/bluez/hci0/dev_<MAC> org.freedesktop.DBus.Properties.Get string:"org.bluez.Battery1" string:"Percentage"
variant byte 50
$ bluetoothctl info <MAC>
Device <MAC> (public)
Name: LE_WH-1000XM3
Alias: LE_WH-1000XM3
...
Battery Percentage: 0x32 (50)before adding the flag the DBus interface was missing, this script reported that the device was in use and bluetoothctl did not have the battery percentage field. However reading battery level when not connected worked. |
|
@Jaakkonen You are probably running a recent version of pipwire after this MR was merged, or PulseAudio built with this MR locally? Both use |
|
@MarijnS95 I'm running pipewire 1:0.3.39 and this is not working for me - the battery level field doesn't appear. |
|
@gshpychka As per the above: Have you enabled BlueZ experimental features/interfaces? |
|
Yes, I've edited the unit file to add the |
|
@gshpychka Your best bet is to check and share debug logs for both bluetoothd and pipewire right after connecting headphones. That usually gives some hints though I'm unfamiliar with PipeWire to give you anything conclusive to check. What type of headphones/speakers do you have - do they support battery reporting at all? |
|
Same headphones as OP. I have this in the pipewire-media-session logs: I'm running BlueZ 5.62 |
|
@gshpychka That sounds like You can check the status to see if it's indeed running with the desired flags: $ systemctl status bluetooth
● bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/bluetooth.service.d
└─override.conf
Active: active (running) since Mon 2021-10-25 13:55:40 CEST; 3s ago
Docs: man:bluetoothd(8)
Main PID: 235559 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 154391)
Memory: 964.0K
CPU: 19ms
CGroup: /system.slice/bluetooth.service
└─235559 /usr/lib/bluetooth/bluetoothd -d -EI locally use FWIW to prevent conflicts with the main unit file installed by your package manager, you should use an override file with [Service]
ExecStart=
ExecStart=/usr/lib/bluetooth/bluetoothd -d -E |
|
Im seeing that this is happening when I am in experimental mode:
|
|
@jamietanna Is PulseAudio or PipeWire running, and built from recent enough source to report this battery level to BlueZ in the first place? Perhaps their logs might clarify what is missing, as |
|
@MarijnS95 I'm running a fairly up-to-date Arch Linux install, with these versions: |
|
@jamietanna As mentioned above PulseAudio must be built with this MR in order to have the feature; it'll only land in 16.0 which should |
|
Oh sorry I totally didn't read that right - awesome will keel an eye out for that release then! |
When running the script for the first time after connecting the headset, it fails with an OSError:
The headset is properly connected and my laptop is transmitting sound, no problems there.
If i run the script again it works as intended, also for any subsequent executions of the program...
I don't know much about bluetooth at this point, but my guess would be that the socket is somehow not properly connecting (just a random guess).
The text was updated successfully, but these errors were encountered: