The problem is that I had to buy a new BT headset because my old headset (Logitech) suffered from a broken cable. This headset used to work flawlessly with EndeavourOS. Also my Bose Color II Soundlink BT speaker works perfectly.
I decided to buy the headset I mentioned in the title (JBL ReflectContour2). I can not figure out how to get this working using EOS. There must be some small detail that I’m missing. I tried to pair it using Plasma BT icon and also using bluetoothctl (terminal based). What makes me wonder is, that the device’s name is not displayed during configuration (only MAC Address). It is nearly impossible to tell which device is the correct one because there are quite a few around.
Any idea about how to solve the issue will be highly appreciated.
If you need any information, just ask and I’ll post it (if possible).
Linux Netbook 5.9.11-arch2-1 #1 SMP PREEMPT Sat, 28 Nov 2020 02:07:22 +0000 x86_64 GNU/Linux
0: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
1: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
01: USB 00.1: 11500 Bluetooth Device
[Created at usb.122]
Unique ID: HyGm.l148Ao7nQK1
Parent ID: cLrx.lRoCB54l1cE
SysFS ID: /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.1/1-2.1:1.1
SysFS BusID: 1-2.1:1.1
Hardware Class: bluetooth
Model: "Intel Bluetooth Device"
Vendor: usb 0x8087 "Intel Corp."
Device: usb 0x0a2a
Driver Modules: "btusb"
Speed: 12 Mbps
Module Alias: "usb:v8087p0A2Ad0001dcE0dsc01dp01icE0isc01ip01in01"
Driver Info #0:
Driver Status: btusb is active
Driver Activation Cmd: "modprobe btusb"
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #3 (Hub)
yay -Qs bluetooth
Bluetooth configuration tool
local/bluedevil 1:5.20.4-1 (plasma)
Integrate the Bluetooth technology within KDE workspace and applications
Daemons for the bluetooth protocol stack
CUPS printer backend for Bluetooth printers
Put HID proxying bluetooth HCI's into HCI mode
Deprecated libraries for the bluetooth protocol stack
A set of tools to manage Bluetooth devices for Linux
Development and debugging utilities for the bluetooth protocol stack
The GNOME Bluetooth Subsystem
Simple library for communicating with USB and Bluetooth HID devices
Bluetooth support for PulseAudio
Bluetooth Subband Codec (SBC) library
[CHG] Controller 40:A3:CC:90:2B:75 Discovering: yes
[NEW] Device C1:A5:D7:6E:06:32 Hue Lamp
[CHG] Device 2E:1F:98:F8:F3:39 RSSI: -73
[NEW] Device 6F:F0:AA:FC:44:B4 6F-F0-AA-FC-44-B4
[NEW] Device 62:93:9D:D5:5E:AC LE-Bose Color II SoundLink
[NEW] Device 60:03:08:D5:08:F3 60-03-08-D5-08-F3
[NEW] Device FC:49:2D:C9:A6:7C Echo Show 5-HPF
[CHG] Device 6B:5E:C0:AD:5F:33 RSSI: -65
[CHG] Device 6B:5E:C0:AD:5F:33 TxPower: 12
[NEW] Device E7:C7:57:1F:0A:05 Hue Lamp
[NEW] Device CF:33:2D:93:FD:4A Hue Lamp
**[NEW] Device 98:52:3D:10:1D:99 98-52-3D-10-1D-99**
[CHG] Device C8:C4:62:31:9D:7A RSSI: -83
[NEW] Device E7:36:AA:55:AF:52 Hue Lamp
[NEW] Device D4:0A:05:87:F7:7E Hue Lamp
I guess the marked device (with the **) is the correct one, although I’m not 100% sure.
Didn’t the instructions say what it’ll show up as? Almost every (good, not dollar-tree level) bluetooth device I’ve ever bought says what the ID string will be when pairing in the manual.
ID as a Hue Lamp seems…odd, doubly since given that Philips Hue stuff ID’s as that.
Just to say, if it works correctly for other devices then it’s not a local configuration issue, so don’t start altering things!
I seem to remember there are some Bluetooth-related fixes in recent kernel updates so it will be worth waiting and seeing whether 5.9.12 resolves this.
According to the quickstart for that headset, it should ID as a “JBL Reflect Countour 2”
According to the manual it is supposed to appear with its actual name. Which it did when I connected it to my mobile phone.
That was my second thought. I didn’t have a look when the headset appeared on the market. In a worst case scenario the hardware is too new and not yet supported. So waiting might be a good idea. Not that I urgently needed the headset working with the netbook, but it would have been a nice to have.
I was thinking something similar. Is that a bluetooth 5 device and maybe your machine is 4.x? I know they’re SUPPOSED to autoresolve and just use the version of the lowest, but I’ve never tested a 5.0 device as of yet (since they’re all too expensive still for me to bother buying just to have a 5.0 device to play with).
Bluetooth version is 4.2. I mainly bought this headset because it is sweat proof and the battery lasts (if fully charged) for about 10 hours. In addition to that the sound quality is very good for a headset not being too expensive (34,48 €).
your mobile not tell mac address if connect ? if you see ,you remember it and connect to computer ( look for mac address.
blueman-manager alway work for me … old still work good
That was exactly my idea when I saw all those devices during the scan. Unluckily I couldn’t find a way to see something different on my mobile phone than the actual name. I could not yet figure out how to display the MAC address on my mobile phone. To me it looks like there is something screwed up in communication between the headset and either the bluetooth chipset of the netbook or the current kernel used by EOS. Unluckily I don’t have a BT dongle for my desktop. If I had one of those I could test the headset with my openSUSE installation to figure out if it’s a general issue or an issue with EOS.
i no think it eos problem… i have few 4.2 +5.0 bluethooth items all connect perfect …
Problem solved. One of the latest kernel, pipewire or bluez updates solved the connection problem.
Today I discovered that I’m able to connect the mentioned headphone to my desktop using my bluetooth stick. When I tried to connect it to my netbook (internal Intel bluetooth chip) it failed miserably. Only the Mac address of the headset has been displayed (not the actual name). So I tried to connect the headset to my netbook using the stick. Still failed because (I assume) it was still using the internal chip. Deactivating the internal chip by blacklisting the modul was not possible because the internal chip uses the same driver as the stick (btusb), so I had to define a new rule in
/etc/udev/rules.d/ with the specific vendor and device id to get rid of the internal chip. After rebooting the stick was used and I was able to connect my headset to the netbook.
Obviously there was an incompatibilty between internal chip and headset besides the system not supporting the headset until recently.
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.