Linux device scanning is weak

[Erhannis]

I've tested the package on Windows, iOS, Mac, Android, and now Linux. With like 40 hours of work, I've gotten it to work fairly reliably across all of these (thank you), except that Linux device scans only occasionally return a device. Since, a la https://github.com/Navideck/universal_ble/issues/69#issuecomment-2332472762 , it appears that scanning a device is crucial to connecting to it, this means difficulties (re)connecting. My instinct is that e.g. Linux is only returning a single result for a device and expecting you to cache it, no matter how long it's been since the last scan - or something. Like, I've turned BLE off and on and then gotten a device in a scan, but otherwise frequently (always?) fail to get the device in a scan. I'll do some more testing later, but atm that's my impression - any thoughts, based on having worked with the API more directly?

[rohitsangwan01]

@Erhannis we are using Bluez internally for Linux, can you try Bluez once to confirm if its UniversalBle issue, or Bluez not discovering devices properly

import 'package:bluez/bluez.dart';

void main() async {
  var client = BlueZClient();
  await client.connect();

  if (client.adapters.isEmpty) {
    print('No Bluetooth adapters found');
    await client.close();
    return;
  }

  BlueZAdapter adapter = client.adapters.first;

  client.deviceAdded.listen((BlueZDevice device) {
    // Get your device here

  });

  adapter.startDiscovery();
}

[Erhannis]

Yeah, adapting the code you gave, when I first start scanning, I get the expected bluetooth devices, but if I stop scanning and start scanning again, nothing is shown. (My impression, again, is that it only reports a given device once per app run, for the most part.) I'm inclined to consider this a failing on BlueZ's part - first, because it's a pain having to cache the results yourself, and second, because caching can't distinguish "devices that are no longer present" from "devices that simply have already been scanned", and so BlueZ does not permit the user to refresh the list of actively visible devices.

[Erhannis]

Ah - poking around the BlueZ git, I do notice there's a "client.devices" list, which contains previously scanned devices. It doesn't really fix the "unknown-stale devices" problem, but perhaps universal_ble could use it to report to listeners on scan re-start, similar as I think happens on other platforms?

[Erhannis]

Ok, I no longer know WHAT exactly BlueZ is doing. Devices are disappearing from client.devices, showing up again in the scan, who knows. Nevertheless, the impression I'm getting from its antics is that if, on scan start, universal_ble were to listen for new devices and also return the list of client.devices, that should give the user the most up-to-date list currently available. It seems like any active device can be found EITHER in client.devices or the subsequent result of a scan.

[rohitsangwan01]

@Erhannis Thank you for the detailed explanation. We're following a similar approach. After calling startScan, we invoke _client.devices and also initiate device discovery. But seems like even after combining both, discovery is not that great compared to other platforms