desktop: Bluetooth download from DC fails in common use case #1002
Comments
|
Could this be related to 1c223b0 ? At the time I tested this on iOS and Mac but it could be breaking Linux (at least I didn't test). |
|
Could be, not sure. Will try this by reverting. |
|
Give me a few minutes, I'm working on a fix. |
bstoeger
added a commit
to bstoeger/subsurface
that referenced
this issue
Dec 31, 2017
If the BT dialog hasn't been shown, the device name was taken from the text field, which contained a formatted string. The device open would then fail. Fixes subsurface#1002 Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
bstoeger
added a commit
to bstoeger/subsurface
that referenced
this issue
Dec 31, 2017
Owing to bug subsurface#1002 invalid bluetooth device addresses of the form "devicename (deviceaddress)" or "deviceaddress (devicename)" may have found their way into the preferences. Recognize such names and extract the correct address. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
bstoeger
added a commit
to bstoeger/subsurface
that referenced
this issue
Dec 31, 2017
Owing to bug subsurface#1002 invalid bluetooth device addresses of the form "devicename (deviceaddress)" or "deviceaddress (devicename)" may have found their way into the preferences. Recognize such names and extract the correct address. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
dirkhh
pushed a commit
that referenced
this issue
Dec 31, 2017
Owing to bug #1002 invalid bluetooth device addresses of the form "devicename (deviceaddress)" or "deviceaddress (devicename)" may have found their way into the preferences. Recognize such names and extract the correct address. Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the issue:
Issue long description:
For some time, I downloaded from mobile, but back home, I like to download from the DC using the desktop application again. This is currently not working correctly. Simply go to the Import from DC screen, and as I always download this way, my BT button is default selected and the device mount point correctly filled with the following string
OSTC3#05106 (00:80:25:4A:0F:C3). This nicely formatted string comes from commit de81eff (@bstoeger). Now click download and it fails (always). First I thought it had something to do with a almost end-of-live battery in my OSTC.There is a workaround, and that points immediately to the reason of this bug. When going to the "remote Bluetooth device selection" screen first, selecting the DC and save it, and then back at the download screen, the download succeeds. Or just manually type in the BT address without the name padding.
Further investigation shows that all this is caused by passing the nicely formatted devname to libdc, and that obviously fails. The workaround route sets the devname to the BT address without the name, so that succeeds.
Operating system:
will fail on Linux, Apple, Windows.
Subsurface version:
latest master
Steps to reproduce:
see description
Current behavior:
see description
Expected behavior:
see description
Additional information:
commit de81eff is related. And I believe this is a high prio issue, as it is a very common use case, and an average user using BT/BLE download will not find the workaround instinctively.
Mentions:
@bstoeger
The text was updated successfully, but these errors were encountered: