connection loop w/ galaxy buds 3 pro

[leochinelato]

App doesn't working in my buds3pro, it connects, and immediately disconnect in app, even when connected via Bluetooth.

I do not understand whats is happening

[vedatkilic]

Thanks for the report and the screenshots — they turned out to be the whole story. There were two separate bugs, both fixed in v1.2.0.

The loop. The app polls for an auto-connect every couple of seconds and retries a silent connect on a 15s cooldown. That silent attempt cleared the visible error state, and the setup screen shows the spinner whenever there's no error and no connection — so a failure was wiped ~15s later and re-appeared on the next timeout, forever. That's exactly the alternation between your two screenshots. A silent auto-connect no longer clears a surfaced error.

The timeout underneath it. Your second screenshot shows "Connection timed out", which came from a single watchdog covering all three connection attempts. I measured the real timings against hardware: openConnection() alone blocks for 3–15 seconds before the service discovery query even starts. On the version you were running the watchdog was 12 seconds, so it fired before the app had looked for the control channel at all. Each attempt now gets its own 35s budget.

Two more changes that may matter for your Buds3 Pro specifically: the app now probes all four SPP service UUIDs Samsung earbuds are known to use instead of only the one expected for the model, and it keeps a connection log you can copy from the About page. If it still fails, that log will tell us exactly where — it records the service records your earbuds advertise, which is the piece I've been missing.

Could you try v1.2.0 and let me know? If it still loops, please paste the output of About → Copy diagnostics.

[vedatkilic]

Small update: please use v1.3.0 rather than v1.2.0 — two more releases landed since my comment above.

v1.2.1 changed how a failed connection is reported. With the earbuds away, macOS keeps serving a stale service record, so the control channel appears to resolve and only the connection attempt reveals nothing is there; that was noticed after 10s but left to idle out against a 35s watchdog. An error now surfaces in about 45s instead of 72s, which should make the loop you saw much easier to tell apart from a slow-but-working connect.

One thing to expect in v1.3.0: the bundle identifier changed, so macOS will ask for Bluetooth permission again on first launch. Allow it, or the app can't reach the earbuds. If you had "Launch at login" on, it needs re-enabling too.

If it still fails on your Buds3 Pro, About → Copy diagnostics and paste the output here. It records the service records your earbuds actually advertise, which is the piece I still can't see from my end.