Mac test build based on Qt5.11.1 - please test

Dirk Hohndel dirk at hohndel.org
Sat Jul 7 06:57:18 PDT 2018


> On Jul 7, 2018, at 12:00 AM, Benjamin <nystire at gmail.com> wrote:
> 
> Subsurface starts up and gives me a red bar at the bottom of the screen saying "Unmatched action 'hash' ", but that could really be my setup, given that Dirk just saved me from a bad data file :) (Thank you, Dirk)

No, I see the same thing here. I'm looking into this.

> Running using Subsurface -v -v
> When trying to import from my Petrel 2, I choose "classic mode" and get the following messages on the CLI:
> Starting download from  BT
> Starting the thread 0
> IOBluetooth works only on the main thread or a thread with a running CFRunLoop
> Failed to connect to device  00:13:43:0C:56:29 . Device state  QBluetoothSocket::UnconnectedState . Error:  QBluetoothSocket::SocketError( -2 )
> qt_ble_open( 00:13:43:0C:56:29 )
> failed to connect to the controller  00:13:43:0C:56:29 with error "Remote device cannot be found"
> Finishing download thread: "Unable to open 00:13:43:0C:56:29 Shearwater (Petrel 2)"
> 

That's interesting. The message on IOBluetooth is a new one - I have noticed that Qt5.11 gives better error messages in a few other situations as well. Also something to investigate.
I assume that you are able to download from your Petrel 2 with the release version of Subsurface 4.8?
Which version of macOS are you on? I created an issue on GitHub to track this: https://github.com/Subsurface-divelog/subsurface/issues/1472 <https://github.com/Subsurface-divelog/subsurface/issues/1472>

> If I choose "BLE mode", then I get the following messages on the CLI:
> Starting download from  BT
> Starting the thread 0
> qt_ble_open( 00:13:43:0C:56:29 )
> failed to connect to the controller  00:13:43:0C:56:29 with error "Remote device cannot be found"
> Finishing download thread: "Unable to open LE:00:13:43:0C:56:29 Shearwater (Petrel 2)"
> 

Has BLE to your Petrel 2 worked with 4.8?

> In both cases, if I try to save the libdivecomputer logfile, I simply get a single line in it:
> Subsurface: v4.8.0, built with libdivecomputer v0.7.0-devel-Subsurface-NG (02560a7e7fe82919d584d3edbf3876f90382052c)
> 

That makes sense - Subsurface doesn't manage to open the connection, so libdivecomputer never gets to play.
I do notice that this says v4.8.0 - so was this even written by the 4.8.0.48 binary that you tried? Or do we write an incorrect version number?

Thanks for testing. This really helps figure out what we need to fix!

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20180707/69cfcb58/attachment-0001.html>


More information about the subsurface mailing list