Re: Suunto Zoop log for Christof's android changes

[Matt Thompson via subsurface]

On Mon, Mar 9, 2020 at 5:29 PM Christof Arnosti  wrote:

> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses two
> different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID / Product
> ID of their cable, and if it works or not? The App
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
> Best regards
> Christof
>
>  Details from my working cable:
  Device Info
Device Path: /dev/bus/usb/001/002
Device Class: Use class information in the Interface Descriptors (0x0)
Vendor ID:  0403
Vendor Name (reported):  Suunto
Vendor Name (from DB):  Future Technology Devices International, Ltd
Product ID:  f680
Product Name (reported):  Suunto Sports Instrument
Product Name (from DB):  not found
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Dirk Hohndel via subsurface]

Yes, you are missing that Android is taking away access to things that look 
like storage from regular apps.
You can access pictures and media files, but you can no longer just read 
storage... Well, in Android 10 you still can, in 11 this will go away.

https://developer.android.com/preview/privacy/storage 


Because of that, I haven't bothered to implement this.

/D

> On Mar 9, 2020, at 4:40 PM, Miika Turkia via subsurface 
>  wrote:
> 
> I should be able to run logcat once I have collected more test data. I just 
> need to figure out how to do that over wifi or BT. Have always connected with 
> usb cable before, but that is not an option this time :)
> 
> BTW I just realized that Garmin is not supported, but it should probably be 
> relatively easy to add. It is mounted as a disk and we need to just point to 
> right mount point. Or am I missing something?
> 
>> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
>> 
>> 
>> Hi,
>> 
>> Thanks. The Info (idVendor / idProduct) is already in the log you sent, so 
>> no need to download the app.
>> 
>> I want to get some (more or less) statistical data about which usb-to-serial 
>> chipset behaves how. This is a big help! :)
>> 
>> If you have some experience in the android world, could you maybe try to run 
>> "adb logcat" while downloading the dives? The logcat output might help with 
>> pinpointing the application crash, and I think until now yours is the only 
>> report of an actual application crash.
>> 
>> Best regards
>> Christof
>> 
>> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>>> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface 
>>> >> > wrote:
>>> Thanks for the more in-depth ;-) test.
>>> 
>>> Having a look at the serial-interface chipset-list at 
>>> http://libdivecomputer.org/drivers.html 
>>>  I noticed that suunto uses two 
>>> different chipsets. Maybe this could be a lead to follow up? 
>>> 
>>> Can the people owning a suunto computer maybe post the Vendor ID / Product 
>>> ID of their cable, and if it works or not? The App  
>>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator 
>>> 
>>>  shows these values.
>>> 
>>> This is what I get on dmesg when attaching the D4 cable:
>>> ---8<---
>>> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
>>> [30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
>>> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2, 
>>> SerialNumber=0
>>> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
>>> [30804.301660] usb 1-2: Manufacturer: Smartinterface
>>> [30804.890118] usbcore: registered new interface driver ftdi_sio
>>> [30804.890187] usbserial: USB Serial support registered for FTDI USB Serial 
>>> Device
>>> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
>>> [30804.890728] usb 1-2: Detected FT232RL
>>> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to 
>>> ttyUSB0
>>> ---8<---
>>> 
>>> Downloading from D4 with this cable on Android 7.1.1, the Subsurface 
>>> crashes after about 4 dives. Do you think the OTG cable plays a part on 
>>> this? I can try the app you mention if that would be beneficial.
>>> 
>>> miika
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

I should be able to run logcat once I have collected more test data. I just 
need to figure out how to do that over wifi or BT. Have always connected with 
usb cable before, but that is not an option this time :)

BTW I just realized that Garmin is not supported, but it should probably be 
relatively easy to add. It is mounted as a disk and we need to just point to 
right mount point. Or am I missing something?

> On 10. Mar 2020, at 6.45, Christof Arnosti  wrote:
> 
> 
> Hi,
> 
> Thanks. The Info (idVendor / idProduct) is already in the log you sent, so no 
> need to download the app.
> 
> I want to get some (more or less) statistical data about which usb-to-serial 
> chipset behaves how. This is a big help! :)
> 
> If you have some experience in the android world, could you maybe try to run 
> "adb logcat" while downloading the dives? The logcat output might help with 
> pinpointing the application crash, and I think until now yours is the only 
> report of an actual application crash.
> 
> Best regards
> Christof
> 
> Am 09.03.20 um 23:39 schrieb Miika Turkia:
>> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface 
>>  wrote:
>>> Thanks for the more in-depth ;-) test.
>>> 
>>> Having a look at the serial-interface chipset-list at 
>>> http://libdivecomputer.org/drivers.html I noticed that suunto uses two 
>>> different chipsets. Maybe this could be a lead to follow up? 
>>> 
>>> Can the people owning a suunto computer maybe post the Vendor ID / Product 
>>> ID of their cable, and if it works or not? The App  
>>> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator 
>>> shows these values.
>>> 
>> This is what I get on dmesg when attaching the D4 cable:
>> ---8<---
>> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
>> [30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
>> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2, 
>> SerialNumber=0
>> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
>> [30804.301660] usb 1-2: Manufacturer: Smartinterface
>> [30804.890118] usbcore: registered new interface driver ftdi_sio
>> [30804.890187] usbserial: USB Serial support registered for FTDI USB Serial 
>> Device
>> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
>> [30804.890728] usb 1-2: Detected FT232RL
>> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to 
>> ttyUSB0
>> ---8<---
>> 
>> Downloading from D4 with this cable on Android 7.1.1, the Subsurface crashes 
>> after about 4 dives. Do you think the OTG cable plays a part on this? I can 
>> try the app you mention if that would be beneficial.
>> 
>> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Jef Driesen via subsurface]

On 9/03/2020 21:37, Christof Arnosti via subsurface wrote:
- Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4 
downloaded drives. There should be a mail with logs in the support mail address.


Do we have a download log for this case? That might give some more clues. I 
didn't find one in the mails. Without those logs we're flying blind, so it's 
always a good idea to provide them right away.


For better debugging I think Jef is right that it would be really nice to have 
timestamps in the libdc-logs. I attached a possible patch (porting of logfunc 
from libdivecomputer to libdivecomputer.c), but I'm currently away from my main 
computer. Maybe somebody could give it a try if it compiles and produces 
timestamps? With this we can check if the read-function still returns too early 
for whatever reason.


This patch won't compile because it tries to use functions and data structures 
from libdivecomputer that are not public.


Jef
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi,

Thanks. The Info (idVendor / idProduct) is already in the log you sent,
so no need to download the app.

I want to get some (more or less) statistical data about which
usb-to-serial chipset behaves how. This is a big help! :)

If you have some experience in the android world, could you maybe try to
run "adb logcat" while downloading the dives? The logcat output might
help with pinpointing the application crash, and I think until now yours
is the only report of an actual application crash.

Best regards
Christof

Am 09.03.20 um 23:39 schrieb Miika Turkia:
> On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface
>  > wrote:
>
> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses
> two different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID /
> Product ID of their cable, and if it works or not? The App 
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
> This is what I get on dmesg when attaching the D4 cable:
> ---8<---
> [30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
> [30804.301648] usb 1-2: New USB device found, idVendor=0403,
> idProduct=6001
> [30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0
> [30804.301657] usb 1-2: Product: USB <-> Serial Cable
> [30804.301660] usb 1-2: Manufacturer: Smartinterface
> [30804.890118] usbcore: registered new interface driver ftdi_sio
> [30804.890187] usbserial: USB Serial support registered for FTDI USB
> Serial Device
> [30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
> [30804.890728] usb 1-2: Detected FT232RL
> [30804.891105] usb 1-2: FTDI USB Serial Device converter now attached
> to ttyUSB0
> ---8<---
>
> Downloading from D4 with this cable on Android 7.1.1, the Subsurface
> crashes after about 4 dives. Do you think the OTG cable plays a part
> on this? I can try the app you mention if that would be beneficial.
>
> miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Miika Turkia via subsurface]

On Tue, Mar 10, 2020 at 6:32 AM Christof Arnosti via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Thanks for the more in-depth ;-) test.
>
> Having a look at the serial-interface chipset-list at
> http://libdivecomputer.org/drivers.html I noticed that suunto uses two
> different chipsets. Maybe this could be a lead to follow up?
>
> Can the people owning a suunto computer maybe post the Vendor ID / Product
> ID of their cable, and if it works or not? The App
> https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
> shows these values.
>
This is what I get on dmesg when attaching the D4 cable:
---8<---
[30804.146977] usb 1-2: new full-speed USB device number 12 using xhci_hcd
[30804.301648] usb 1-2: New USB device found, idVendor=0403, idProduct=6001
[30804.301653] usb 1-2: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
[30804.301657] usb 1-2: Product: USB <-> Serial Cable
[30804.301660] usb 1-2: Manufacturer: Smartinterface
[30804.890118] usbcore: registered new interface driver ftdi_sio
[30804.890187] usbserial: USB Serial support registered for FTDI USB Serial
Device
[30804.890504] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[30804.890728] usb 1-2: Detected FT232RL
[30804.891105] usb 1-2: FTDI USB Serial Device converter now attached to
ttyUSB0
---8<---

Downloading from D4 with this cable on Android 7.1.1, the Subsurface
crashes after about 4 dives. Do you think the OTG cable plays a part on
this? I can try the app you mention if that would be beneficial.

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Thanks for the more in-depth ;-) test.

Having a look at the serial-interface chipset-list at
http://libdivecomputer.org/drivers.html I noticed that suunto uses two
different chipsets. Maybe this could be a lead to follow up?

Can the people owning a suunto computer maybe post the Vendor ID /
Product ID of their cable, and if it works or not? The App 
https://play.google.com/store/apps/details?id=aws.apps.usbDeviceEnumerator
shows these values.

Best regards
Christof

Am 09.03.20 um 23:20 schrieb Matt Thompson via subsurface:
>
> On Mon, Mar 9, 2020 at 3:40 PM Christof Arnosti via subsurface
>  > wrote:
>
> Hi everybody,
>
> There seems to be some general problems with Suunto dive computer
> synchronisation.
>
> We got reports so far from the following Suunto computers which
> use some different libdivecomputer-classes (according to
> 
> https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv):
>
> - Suunto Zoop (uses SUUNTO_VYPER): Does not work. After
> Timeout-Fix: First read returns size=0
> - Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after
> about 4 downloaded drives. There should be a mail with logs in the
> support mail address.
> - Suunto D4i (uses SUUNTO_D9): Report of working download
> - Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on
> "Connecting", might be because of unofficial cable.
>
> The "sleep and purge to surpress possible echo" thing seems to be
> exclusive to the suunto_vyper computers.
>
> What I find interesting is that the D4 and D4i (which are using
> the same driver suunto_d9) have different results.
>
> For my first round of testing with the D4i, I didn't have any new
> dives so I was tecnically only reporting that the communication was
> successful. I did a force download of all dives on my D4i and was able
> to successfully download ~150 dives.  I didn't check profiles but the
> dates and times looked reasonable.
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Matt Thompson via subsurface]

On Mon, Mar 9, 2020 at 3:40 PM Christof Arnosti via subsurface <
subsurface@subsurface-divelog.org> wrote:

> Hi everybody,
>
> There seems to be some general problems with Suunto dive computer
> synchronisation.
>
> We got reports so far from the following Suunto computers which use some
> different libdivecomputer-classes (according to
> https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv
> ):
>
> - Suunto Zoop (uses SUUNTO_VYPER): Does not work. After Timeout-Fix: First
> read returns size=0
> - Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4
> downloaded drives. There should be a mail with logs in the support mail
> address.
> - Suunto D4i (uses SUUNTO_D9): Report of working download
> - Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on "Connecting", might
> be because of unofficial cable.
>
> The "sleep and purge to surpress possible echo" thing seems to be
> exclusive to the suunto_vyper computers.
>
> What I find interesting is that the D4 and D4i (which are using the same
> driver suunto_d9) have different results.
>
> For my first round of testing with the D4i, I didn't have any new dives so
I was tecnically only reporting that the communication was successful. I
did a force download of all dives on my D4i and was able to successfully
download ~150 dives.  I didn't check profiles but the dates and times
looked reasonable.
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Suunto Zoop log for Christof's android changes

[Christof Arnosti via subsurface]

Hi everybody,

There seems to be some general problems with Suunto dive computer
synchronisation.

We got reports so far from the following Suunto computers which use some
different libdivecomputer-classes (according to
https://github.com/Subsurface-divelog/subsurface/blob/master/descriptor3.tsv):

- Suunto Zoop (uses SUUNTO_VYPER): Does not work. After Timeout-Fix:
First read returns size=0
- Suunto D4 (uses SUUNTO_D9): App (or Download?) Crashes after about 4
downloaded drives. There should be a mail with logs in the support mail
address.
- Suunto D4i (uses SUUNTO_D9): Report of working download
- Suunto Vyper Air (uses SUUNTO_VYPER2): Gets stuck on "Connecting",
might be because of unofficial cable.

The "sleep and purge to surpress possible echo" thing seems to be
exclusive to the suunto_vyper computers.

What I find interesting is that the D4 and D4i (which are using the same
driver suunto_d9) have different results.

For better debugging I think Jef is right that it would be really nice
to have timestamps in the libdc-logs. I attached a possible patch
(porting of logfunc from libdivecomputer to libdivecomputer.c), but I'm
currently away from my main computer. Maybe somebody could give it a try
if it compiles and produces timestamps? With this we can check if the
read-function still returns too early for whatever reason.

Best regards
Christof


Am 09.03.20 um 11:19 schrieb Stephen Goodall:
> Hi christof,
> I'm still getting "failed to receive answer" for the Suunto, Cressi is
> still working so the timeout change is good for that one and hasn't
> broken it or anything. Is the version below the correct one?
>
> Suunto:
>
> Subsurface: v4.9.3-1050-g38ca3f684202, built with libdivecomputer
> v0.7.0-devel-Subsurface-NG (0714e327b70bb08f5289c9781c09dc10884881c9)
> INFO: Open: transport=1
> INFO: Configure: baudrate=2400, databits=8, parity=1, stopbits=0,
> flowcontrol=0
> INFO: Timeout: value=1000
> INFO: DTR: value=1
> INFO: Sleep: value=100
> INFO: Purge: direction=3
> INFO: Sleep: value=500
> INFO: RTS: value=1
> INFO: Write: size=5, data=0500161407
> INFO: Sleep: value=200
> INFO: Purge: direction=1
> INFO: RTS: value=0
> INFO: Read: size=0, data=
> ERROR: Failed to receive the answer. [in
> /__w/subsurface/subsurface/libdivecomputer/src/suunto_vyper.c:212
> (suunto_vyper_transfer)]
>
>
> Is there any way to get more verbose libdivecomputer logs or something?
>
> Cheers
>
>
>
> On Mon, 9 Mar 2020, 2:26 am Christof Arnosti,  > wrote:
>
> Hi Stephen,
>
> The build with the improved timeout handling is finished, the
> result is at
> 
> https://github.com/Subsurface-divelog/subsurface/suites/506855270/artifacts/2655791
> . Can you test again with your computers?
>
> Thanks
> Christof
>
> On 08.03.20 15:38, Christof Arnosti wrote:
>>
>> So I just opened a pull request
>> (https://github.com/Subsurface-divelog/subsurface/pull/2656).
>> With this the CI will build the updated version and we can test
>> again with our computers. The Mares Puck Pro still works as expected.
>>
>> Best regards
>> Christof
>>
>> On 08.03.20 14:39, Christof Arnosti wrote:
>>>
>>> Hi Jef,
>>>
>>> Thanks for your comments.
>>>
>>> On 08.03.20 09:27, Jef Driesen wrote:
 On 8/03/2020 06:31, Dirk Hohndel wrote:
>> On Mar 7, 2020, at 9:17 PM, Stephen Goodall
>> > 
>> 
>> > wrote:
>> Subsurface: v4.9.3-1049-g4529add7053f, built with
>> libdivecomputer v0.7.0-devel-Subsurface-NG
>> (0714e327b70bb08f5289c9781c09dc10884881c9)
>> INFO: Open: transport=1
>> INFO: Configure: baudrate=2400, databits=8, parity=1,
>> stopbits=0, flowcontrol=0
>> INFO: Timeout: value=1000
>> INFO: DTR: value=1
>> INFO: Sleep: value=100
>> INFO: Purge: direction=3
>> INFO: Sleep: value=500
>> INFO: RTS: value=1
>> INFO: Write: size=5, data=0500161407
>> INFO: Sleep: value=200
>> INFO: Purge: direction=1
>> INFO: RTS: value=0
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: size=0, data=
>> INFO: Read: 

Re: Switching dive computers

[Miika Turkia via subsurface]

On Mon, Mar 9, 2020 at 4:53 PM Berthold Stoeger via subsurface <
subsurface@subsurface-divelog.org> wrote:

> On Montag, 9. März 2020 09:47:03 CET Robert Helling via subsurface wrote:
> > > On 8. Mar 2020, at 22:12, Dirk Hohndel  wrote:
> > >
> > > I've tried on two Macs and one Linux system with the latest master and
> it
> > > works fine... not sure what Miika did to his system...
> > back at the office. The version I had there definitely showed the
> problem.
> > But a fresh build of current master is ok.
>
> The weird thing is: I see the issue, but only on single-DC dives. However,
> I
> can't figure out where the check is made whether there is only one or
> multiple
> DCs. Very obscure.
>

After one more pull-build cycle, this is working for me as well. Single-DC
dives are still working as described before, but I would not worry about
that..

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Miika Turkia via subsurface]

On Mon, Mar 9, 2020 at 8:37 AM Dirk Hohndel  wrote:

>
>
> > On Mar 8, 2020, at 4:18 PM, Miika Turkia  wrote:
> >
> > I failed to download from Suunto Vyper Air. This might be due to Chinese
> USB-serial adaptor i use. As the cable I have is serial DL cable. The
> status got stuck to Connecting...
>
> If you tried the first beta, that was lacking timeout support. The second
> beta that was released a few hours ago should have that fixed. I'd
> appreciate if you could try again with that one.
>

Looks to be the same. Version I just downloaded from play beta seems to be
4.9.3.1050.


> > I should have a Suunto USB cable at home as well, but I don't remember
> if I was able to soldier it together or not (weak soldering from
> manufacturer) So I might be able to test that option next week.
>
> Cool. Thanks
>

I just realized we have also Suunto D4 with official USB cable with us.
That starts downloading, but crashes after about 4 dives are loaded.
Crashed every time I tried. I did send feedback or whatever it offered to
send after the crash. Not sure if the logs are useful, but best what I
could do atm.

miika
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Switching dive computers

[Berthold Stoeger via subsurface]

On Montag, 9. März 2020 09:47:03 CET Robert Helling via subsurface wrote:
> > On 8. Mar 2020, at 22:12, Dirk Hohndel  wrote:
> > 
> > I've tried on two Macs and one Linux system with the latest master and it
> > works fine... not sure what Miika did to his system...
> back at the office. The version I had there definitely showed the problem.
> But a fresh build of current master is ok.

The weird thing is: I see the issue, but only on single-DC dives. However, I 
can't figure out where the check is made whether there is only one or multiple 
DCs. Very obscure.

Berthold


___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Switching dive computers

[Robert Helling via subsurface]

Hi,

> On 8. Mar 2020, at 22:12, Dirk Hohndel  wrote:
> 
> I've tried on two Macs and one Linux system with the latest master and it 
> works fine... not sure what Miika did to his system...

back at the office. The version I had there definitely showed the problem. But 
a fresh build of current master is ok.

Best
Robert


signature.asc
Description: Message signed with OpenPGP
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface