> On Sep 29, 2018, at 1:24 PM, Lubomir I. Ivanov <neolit...@gmail.com> wrote: >> >> In the meantime, I completed a compile of Qt 5.11.2 from source, added >> your wip/win qtconnectivity and did a make install to make sure that ALL >> of the files are copied to the right place. >> >> I created an installer from that (which is missing FB, printing, user manual, >> and apparently for some reason even the maps). You can find it on our website >> as >> http://subsurface-divelog.org/downloads/test/subsurface-4.8.2-92-gb05b8de05966.exe >> > > do i need to test this installer, given it already worked with -91?
Well, the difference is that this is now all Qt 5.11 based, but you are right, not much incremental value in you testing that... > also TMK the -91 would have all the above modules that -92 is missing? > why do we need to upgrade to 5.11.2? We don't. I was hoping this would help with BLE, but it didn't. >> I then purchased a new copy of Windows 10 (the things we do for our >> hobbies) and installed it on the same laptop that I do my "on hardware" >> Linux testing on. >> >> I paired the Teric with Windows (no problem there at all, found it right >> away). >> >> So now we have: >> - different laptop >> - different BT device (this is a USB dongle, other one was built in) >> - different Windows 10 install >> - NO anti virus, anything >> >> Still the exact same experience in Subsurface >> Regardless if I select Auto or Force LE, I get the Device discovery error. >> And I get it fairly quickly. >> >> If I put my BT-classic-only Petrel in BT mode, it gets detected within a >> second or two, and I can immediately download from it (without having >> to do any pairing first). >> >> So BT works, but somehow the BLE scan results in an error. >> > > we might have a lurking bug in our discovery code. > i need to have a detailed look at it. I think so. >> You know the code much better than I do... in the scan path, what can >> create such an error? One thing that is odd about my office is that I can >> see more than a dozen BLE devices here on a regular scan. I wonder >> if one of the unpaired ones is causing this behavior. But give then need >> to pair first for BLE, that does seem unlikely, doesn't it? > > as mentioned multiple times the Windows discovery and device > enumeration is super shaky. > i don't have other devices in my room and the detection works fine. > > please bring this problem device to Sofia. I'm bringing you one of them :-) >> Is there a way to get more debug info from the Qt BLE code to see WHY >> it created that error? >> > > if QtConnectivity is built in debug mode and if you can try moving > this from qt-ble.cpp > QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = true")); > > to btdiscovery.cpp, it might output are better detailed message. I'll play with that. > i only got the error if i completely disabled BT from control planel. > hard to say, will have another look. > >> My plan for 4.8.3 is to switch back to my previous MXE setup so we have >> working Windows binaries with all components (but not BLE). But I really >> want to push on this BLE story. It feels like we are SO CLOSE. >> > > given it works for me and Steven, it really feels like an isolated error. > is there are change we can announce -91 for testing so that we can > gather more feedback? > > it feels like my installer is not reaching out to people. Let me try to add more debug output and then I'll create a new installer for people to test with. Thanks /D _______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface