Skip to content
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

[BUG] "Bad file descriptor" when using "Enter pairing mode" option #422

Open
dogtopus opened this issue Aug 24, 2023 · 1 comment
Open
Assignees
Labels
bug Something isn't working

Comments

@dogtopus
Copy link

Describe the bug

"Enter pairing mode" option does not put the buds into pairing mode, instead "Bad file descriptor" is shown and causes the app to not communicate to the buds unless the app is restarted.

To Reproduce
Steps to reproduce the behavior:

  • Open app when buds are connected
  • Select System -> Enter pairing mode

Expected behavior

Buds entering pairing mode.

Screenshots

error

Desktop (please complete the following information):

  • OS: Fedora 38
  • Application version: 4.5.3.0 (GPLv3) (Flatpak)

Additional context

Hardware: Galaxy Buds Live (rev0.5)
Firmware: R180XXU0AVJ1 (2022.10.12/00.02.33/SWHD7404)

Log files

2023-08-24 21:10:34.090 +00:00 [INF] Using settings file at: /home/user/.var/app/me.timschneeberger.GalaxyBudsClient/data/GalaxyBudsClient/config.json
2023-08-24 21:10:34.437 +00:00 [INF] SingleInstanceWatcher: Server listening at tcp:host=::1,port=54532
2023-08-24 21:10:35.216 +00:00 [DBG] BluetoothImpl: Using Linux.BluetoothService
2023-08-24 21:10:35.235 +00:00 [INF] Translator mode file location: /home/user/.var/app/me.timschneeberger.GalaxyBudsClient/data/GalaxyBudsClient/custom_language.xaml
2023-08-24 21:10:35.236 +00:00 [INF] User script directory: /home/user/.var/app/me.timschneeberger.GalaxyBudsClient/data/GalaxyBudsClient/scripts
2023-08-24 21:10:35.247 +00:00 [INF] ScriptManager: 0 user script(s) found
2023-08-24 21:10:35.247 +00:00 [DBG] MainWindow.Instance: Initializing window with default WindowImpl
2023-08-24 21:10:35.602 +00:00 [WRN] StubDeviceSpec: initialized
2023-08-24 21:10:35.679 +00:00 [DBG] FirmwareRemoteClient: Searching for firmware binaries...
2023-08-24 21:10:35.955 +00:00 [WRN] StubDeviceSpec: initialized
2023-08-24 21:10:35.960 +00:00 [DBG] Linux.BluetoothService: No adapter preselected. Choosing default one.
2023-08-24 21:10:35.974 +00:00 [DBG] Linux.BluetoothService: Using Bluetooth adapter: hci0
2023-08-24 21:10:35.985 +00:00 [DBG] Linux.BluetoothService: Connecting... (attempt 1/5)
2023-08-24 21:10:35.990 +00:00 [DBG] Linux.BluetoothService: Device ready. Registering profile client for UUID 00001101-0000-1000-8000-00805f9b34fb...
2023-08-24 21:10:35.992 +00:00 [DBG] Linux.BluetoothService: Connecting to profile... (attempt 1/10)
2023-08-24 21:10:36.100 +00:00 [WRN] Dummy.HotkeyReceiver: Platform not supported
2023-08-24 21:10:36.180 +00:00 [DBG] Linux.BluetoothSocket: Connected to profile
2023-08-24 21:10:36.181 +00:00 [DBG] Linux.BluetoothService: Connection established. Launching BluetoothServiceLoop.
2023-08-24 21:10:36.217 +00:00 [DBG] Linux.BluetoothService: Using Bluetooth adapter: hci0
2023-08-24 21:10:36.435 +00:00 [DBG] FirmwareRemoteClient: 0 firmware found.
2023-08-24 21:10:36.993 +00:00 [DBG] SpatialAudioDataParser: Unknown id (38)
2023-08-24 21:10:37.395 +00:00 [DBG] SpatialAudioDataParser: Unknown id (38)
2023-08-24 21:10:37.636 +00:00 [WRN] NoiseControlSwitchMode: Unknown mode
2023-08-24 21:10:38.607 +00:00 [WRN] NoiseControlSwitchMode: Unknown mode
2023-08-24 21:10:39.415 +00:00 [WRN] NoiseControlSwitchMode: Unknown mode
2023-08-24 21:10:40.629 +00:00 [WRN] NoiseControlSwitchMode: Unknown mode
2023-08-24 21:10:41.336 +00:00 [DBG] ExperimentClient: Scanning for experiments...
2023-08-24 21:10:41.437 +00:00 [WRN] NoiseControlSwitchMode: Unknown mode
2023-08-24 21:10:42.871 +00:00 [DBG] Linux.BluetoothService: Disconnecting...
2023-08-24 21:10:42.872 +00:00 [DBG] Linux.BluetoothService: Cancelling BluetoothServiceLoop...
2023-08-24 21:10:42.877 +00:00 [DBG] Linux.BluetoothSocket: Disconnection requested
2023-08-24 21:10:42.878 +00:00 [DBG] Linux.BluetoothService: Disconnecting...
2023-08-24 21:10:42.879 +00:00 [DBG] Linux.BluetoothService: Cancelling BluetoothServiceLoop...
2023-08-24 21:10:42.880 +00:00 [DBG] Linux.BluetoothService: Profile disconnected
2023-08-24 21:10:42.880 +00:00 [DBG] Linux.BluetoothService: Profile disconnected
2023-08-24 21:10:42.882 +00:00 [WRN] Linux.BluetoothService: (Non-critical) Exception raised while unregistering profile: org.bluez.Error.DoesNotExist: Does Not Exist
2023-08-24 21:10:42.883 +00:00 [WRN] Linux.BluetoothService: (Non-critical) Exception raised while unregistering profile: org.bluez.Error.DoesNotExist: Does Not Exist
2023-08-24 21:10:43.003 +00:00 [ERR] Linux.BluetoothService: BluetoothServiceLoop: SocketException thrown while reading unsafe stream: Error 9: Bad file descriptor. Cancelled.
2023-08-24 21:10:43.004 +00:00 [ERR] Linux.BluetoothService: BluetoothServiceLoop: UnixException thrown while handling unsafe stream: Error 9: Bad file descriptor. Cancelled.
2023-08-24 21:10:45.929 +00:00 [INF] MainWindow.TitleBar: Close requested, exiting app
2023-08-24 21:10:45.933 +00:00 [DBG] MainWindow.OnClosing: Now closing session
2023-08-24 21:10:45.972 +00:00 [INF] MainWindow: Shutting down normally
@dogtopus dogtopus added the bug Something isn't working label Aug 24, 2023
@dogtopus
Copy link
Author

dogtopus commented Aug 29, 2023

OK so this option seems to send an undocumented command which may not present on Live.

For Live at least, seems like the only way to enter pairing mode is to disable the Bluetooth on the device it previously connected to and power cycle the buds (put them back into the case, close the lid and open the lid again). The documentation on "unused pairing mode" also gives a clue about a way that I didn't know previously:

This is probably left-over from the original Galaxy Buds firmware, as they supported to enter pairing mode when both touchpads were simultaneously long-pressed.

It's also mentioned in the manual but buried way down under the "using our app to pair" stuff so that's probably why I missed it.

So simply put: This feature in the app should not be used or should be disabled on older buds. Or better: hint the user about the alternative way of entering pairing mode when the buds are a known set that don't support the pairing command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants