Sorry to hear about your dive computer - but very happy that you reported back
success with the AppImage.
/D
> On Sep 23, 2019, at 1:22 PM, David Tillotson wrote:
>
> Happy to report that this works perfectly (as far as I can test :)
> Unfortunately I can't test it as much as I'd like, as my
On Mon, 23 Sep 2019 16:46:53 +0100
Paul Buxton wrote:
> David,
> If you want to test the Appimage linked to at the bottom of this
> pull request
> https://github.com/Subsurface-divelog/subsurface/pull/2300
>
> I believe it should fix the issue you were seeing?
>
Happy to report that this
David,
If you want to test the Appimage linked to at the bottom of this pull request
https://github.com/Subsurface-divelog/subsurface/pull/2300
I believe it should fix the issue you were seeing?
On Thu, Sep 19, 2019 at 6:59 PM Paul Buxton
wrote:
>
> So to summarise.
> Your machine-id is in
You've done this absolutely correctly - thank you for figuring this out. It
really helps us significantly.
You are confirming the suspicion that Berthold and I have had that this is
indeed a bug in how we deal with a dynamic data structure for the downloaded
dives.
> On Sep 23, 2019, at 5:37
On 16 September, 2019 - Dirk Hohndel wrote:
>
> > On Sep 16, 2019, at 3:43 AM, Björn S wrote:
> > The Samsung S9 is part of the long list of Android devices that prevent the
> > way Subsurface-mobile tries to access FTDI devices.
> > Right now there is no workaround - really nothing you can
I dont know if Ive done this right as I have never used Android Studio and ADB
before.
However, this is the verbose logcat from roughly the point that I start the
process to download via bluetooth and then pressing the cancel button to
generate the crash.
2019-09-23 13:26:06.767 14241-14256/?
