Re: SubSurface Mobile and OTG

[Miika Turkia]

On Wed, May 23, 2018 at 11:55 AM, Guillaume Gardet  wrote:

> Hi,
>
> Le 23/05/2018 à 07:29, Miika Turkia a écrit :
>
> This does work for some divecomputers, depending on the ftdi chip that is
> used on the cable. We also have some trouble with Android OS as some newer
> Android versions prevent us from accessing the USB devices. What versions
> of DC, cable (the serial chip), phone and Android you are using? (I have
> used OTG on Nexus 7 tablet and Suunto Vyper Air DC successfully, don't
> remember the Android version on the tablet.)
>
>
> Does it still work? Because Vyper Air on a Nexus 7 fails for me. :(
>

Couldn't find the original cable for Vyper air, but tested with D4. Failed
:(

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Aaron Scheiner]

I just tried re-downloading logs from my Petrel 2 using both the current
beta Android app and the current Windows application available for download
(4.7.8) and neither downloaded the PO2 samples.

So I'm experiencing the same bug :D .

Aaron

The libdivecomputer log file

ends with the following :
INFO: Write: size=6, data=FF01020037C0
INFO: Read: size=1, data=01
INFO: Read: size=1, data=FF
INFO: Read: size=1, data=03
INFO: Read: size=1, data=00
INFO: Read: size=1, data=77
INFO: Read: size=1, data=00
INFO: Read: size=1, data=C0
INFO: Shearwater log version 7

WARNING: Disabled all O2 sensors due to a default calibration value. [in
/home/travis/build/Subsurface-divelog/subsurface/libdivecomputer/src/
shearwater_predator_parser.c:503 (shearwater_predator_parser_cache)]
INFO: Write: size=9, data=FF0105002E902000C0


On Wed, May 23, 2018 at 5:01 PM, Davide DB  wrote:

> Cool, thanks!
> On Wed, 23 May 2018 at 16:58, Aaron Scheiner  wrote:
>
> > Yes, all three sensor values are rendered and they tend towards the set
> point, which is also rendered. They show on both the desktop and Android
> apps (for me).
>
> > I'll be home soon, I'll try downloading them into a clean profile with
> the absolute latest software and see what happens.
>
> > On Wed, May 23, 2018, 16:51 Davide DB  wrote:
>
> >> On Wed, 23 May 2018 at 16:37, Aaron Scheiner 
> wrote:
>
> >> > I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer
> attached.
>
> >> > I do all my downloads using the Android app (I'm on the beta channel)
> and
> >> I mostly view the data on Linux. I never use the Shearwater desktop
> >> application. I haven't noticed any discrepancies in the data so far.
>
> >> > I'm hoping to dive this weekend, I'll revert back with additional
> >> feedback once I've dived.
>
>
> >> So, regardless of their correctness,  do you confirm that you see pO2
> >> samples in Subsurface?
>
> >> Thanks
>
>
>
> --
> Davide
> https://vimeo.com/bocio/videos
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Segfault with Qt-5.11.0

[Gaetan Bisson]

[2018-05-23 07:12:45 -1000] Gaetan Bisson:
> [2018-05-23 10:28:52 -0300] Thiago Macieira:
> > On Wednesday, 23 May 2018 05:08:58 -03 Gaetan Bisson wrote:
> > > Any ideas how to debug this?
> > 
> > Can you valgrind? Without debug symbols in Qt it may be a little difficult 
> > to 
> > make sense of what we're seeing, but it might help.
> 
> Sure; see valgrind's log attached. The core dump is too big to send by
> email but I can find a way to get it to you if needed. Also, while I was
> asleep, Arch's Qt packager bisected the faulty commit to:
> 
>   
> http://code.qt.io/cgit/qt/qtbase.git/patch/?id=1c0fcbc887459d8963088309e83303eb1a7d2db0
>   
> Which I note is also suspected for other segfaults:
> 
>   https://github.com/lxqt/libfm-qt/issues/164
> 
> He has reported this issue there:
> 
>   https://bugreports.qt.io/browse/QTBUG-68427

Oh, it's also there:

https://bugreports.qt.io/browse/QTBUG-67948

Cheers.

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

Cool, thanks!
On Wed, 23 May 2018 at 16:58, Aaron Scheiner  wrote:

> Yes, all three sensor values are rendered and they tend towards the set
point, which is also rendered. They show on both the desktop and Android
apps (for me).

> I'll be home soon, I'll try downloading them into a clean profile with
the absolute latest software and see what happens.

> On Wed, May 23, 2018, 16:51 Davide DB  wrote:

>> On Wed, 23 May 2018 at 16:37, Aaron Scheiner  wrote:

>> > I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer
attached.

>> > I do all my downloads using the Android app (I'm on the beta channel)
and
>> I mostly view the data on Linux. I never use the Shearwater desktop
>> application. I haven't noticed any discrepancies in the data so far.

>> > I'm hoping to dive this weekend, I'll revert back with additional
>> feedback once I've dived.


>> So, regardless of their correctness,  do you confirm that you see pO2
>> samples in Subsurface?

>> Thanks



-- 
Davide
https://vimeo.com/bocio/videos
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Hashing videos

[Linus Torvalds]

On Wed, May 23, 2018 at 1:01 AM Robert Helling  wrote:

> So my choice would be: Completely ignore filename and path, but maybe
take into account length and creation date.

I would disagree. Moving machines, or having the same pictures just on
multiple machines, means that you definitely do not want to take creation
date into account.

Also, I suspect that if you *do* end up photoshopping the picture (fixing
color etc), you would still want it referenced.

So I think it should just do it by filename (not path, although maybe you
want to match up directories "eagerly" - save the path, and use as much of
it as possible, but search for pictures just by filename if you don't find
it in the primary location).

The hashing was always questionable. I think it came from the original "put
the whole picture in the repository" which was a complete disaster.

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Aaron Scheiner]

Yes, all three sensor values are rendered and they tend towards the set
point, which is also rendered. They show on both the desktop and Android
apps (for me).

I'll be home soon, I'll try downloading them into a clean profile with the
absolute latest software and see what happens.

On Wed, May 23, 2018, 16:51 Davide DB  wrote:

> On Wed, 23 May 2018 at 16:37, Aaron Scheiner  wrote:
>
> > I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer
> attached.
>
> > I do all my downloads using the Android app (I'm on the beta channel) and
> I mostly view the data on Linux. I never use the Shearwater desktop
> application. I haven't noticed any discrepancies in the data so far.
>
> > I'm hoping to dive this weekend, I'll revert back with additional
> feedback once I've dived.
>
>
> So, regardless of their correctness,  do you confirm that you see pO2
> samples in Subsurface?
>
> Thanks
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Hashing videos

[Berthold Stoeger]

On Mittwoch, 23. Mai 2018 16:31:54 CEST Robert Helling wrote:

> > On 23. May 2018, at 15:23, Berthold Stoeger 
> > wrote:
> 
> I don’t think backwards compatibility is any problem at all: At worst, with
> a new version of hashes we get some cache misses and have to once load the
> actual file. So startup is slower when first running a new version.

Wouldn't the whole "Find moved pictures" functionality fail if we changed the 
hash-algorithm?

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

On Wed, 23 May 2018 at 16:37, Aaron Scheiner  wrote:

> I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer attached.

> I do all my downloads using the Android app (I'm on the beta channel) and
I mostly view the data on Linux. I never use the Shearwater desktop
application. I haven't noticed any discrepancies in the data so far.

> I'm hoping to dive this weekend, I'll revert back with additional
feedback once I've dived.


So, regardless of their correctness,  do you confirm that you see pO2
samples in Subsurface?

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

On Wed, 23 May 2018 at 16:22, Jef Driesen  wrote:

> On 2018-05-23 14:58, Davide DB wrote:
> > On Wed, May 23, 2018, 12:08 Willem Ferguson
> > 
> > wrote:
> >> If this is the case, then the problem should in principle be solvable
> >> and it possibly means that the coding in the dive log is slightly
> >> different from that of the standard Petrel and the Fischer Petrel 2.
> >> The
> >> most knowledgeable person to approach is Jef Driesen but he would need
> >> some specific information from your download. A first approach is to
> >> inspect the .bin dumpfile generated for debug in Subsurface. Then use
> >> his dctool executable (If I remember correctly it can do Bluetooth and
> >> it is extremely flexible) and see if you can trace the pO2 values.
> >>
> >> I am not sure this is what you may want to hear, but assume that (if
> >> you
> >> want the problem solved) you need to take the initiative. You may
> >> possibly be the only person in this circle which has a divecan Petrel
> >> so
> >> you are in the best position to address the problem.
> >>
> >
> > While I do not pretend anything (of course), regarding your questions I
> > can
> > assure you that I made everything I could as end user. I gave
> > - Shearwater desktop screenshots
> > - Shearwater xml exported logs
> > - Subsurface xml logs
> > - Subsurface bin dumps
> > - dctool dump files
> >
> > My only fault was not filing a bug report on Github to resume
> > everything in
> > one place.
> > I even asked on the list if someone else was using a Shearwater Petrel
> > ECCR
> > controller and, maybe experiencing the same behavior. No reply. So I
> > don't
> > know if it's my specific unit or not.
> > BTW I recently updated Petrel firmware to the latest version without
> > results. While it's possible I'm the only Shearwater ccr user on this
> > list,
> > we are speaking of the most common eccr controller on the market
> > nowadays.
> > It's used on countless rebreathers not an obscure dive computer
> > implementation.
> >
> > Everything started months ago when I discovered that pO2 samples
> > reported
> > by Subsurface were completely different (and wrong) from Shearwater
> > desktop.
> > There was a long email thread in which AFAIK no solution was found: my
> > Petrel is strange.
> > Maybe I missed something and Jef or Anton modified something. I don't
> > know
> > but at some point pO2 samples disappeared from Subsurface hence I
> > opened
> > this thread but I'm failing to understand what "default calibration"
> > means
> > and why in my logbook I find the same device listed with random number
> > of
> > sensors.
> > I asked again today because because even a "guy you must die!" reply
> > it's
> > ok but I got no replies at all.

> Sorry for the lack of response, but for the last few weeks, I was just
> too busy with non-libdivecomputer related things.

> Anyway, the problem is as follows. The shearwater devices record two
> different things:

>  1. The average/voted ppO2.

>  2. The value from each O2 sensor. Unfortunately this value is not the
> ppO2 value, but the raw millivolt measurement from the sensor. In order
> to convert this value to a ppO2 value, we need to take into account the
> calibration values.

> Last time I checked, shearwater desktop only shows the average/voted
> ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2) at
> all (e.g. no millivolt values nor the converted ppO2).

> Now, originally libdivecomputer only reported the average/vote ppO2.
> Later on we figured out how the sensor calibration worked, and this was
> replaced with the ppO2 value from the individual sensors. But afterwards
> we also discovered that some devices (like the one from Davide) don't
> seem to store the calibration values correctly, and leave them at their
> default values (2100). I have no idea why this happens. Anyway, because
> applying those calibration values produces incorrect ppO2 values, I
> added some code to detect this case and disable the ppO2 from the
> sensors. Since the average/voted ppO2 was already disabled earlier, that
> also means you won't get any ppO2 values at all anymore.

> For those bogus default calibration values, there is not much we can do
> about that. Without the (correct) calibration values, we simply can't
> calculate the ppO2 values. So unless the calibration values are for some
> reason stored elsewhere, and we just don't know about this, we're simply
> stuck here. Shearwater desktop doesn't show this info, so it's difficult
> to tell what's going on.

> The only part that we can do something about, is restoring the
> average/voted ppO2 again. That's already on my todo list. But right now
> the libdivecomputer api doesn't have a way to indicate the type of the
> ppO2 value (e.g. average/voted or from an individual sensor), so that
> would cause confusing. So this will require some (backwards
> incompatible) changes, and that's why 

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Anton Lundin]

On 23 May, 2018 - Anton Lundin wrote:

> On 23 May, 2018 - Jef Driesen wrote:
> 
> > On 2018-05-23 14:58, Davide DB wrote:
> > >On Wed, May 23, 2018, 12:08 Willem Ferguson
> > >
> > >wrote:
> > >>If this is the case, then the problem should in principle be solvable
> > >>and it possibly means that the coding in the dive log is slightly
> > >>different from that of the standard Petrel and the Fischer
> > >>Petrel 2. The
> > >>most knowledgeable person to approach is Jef Driesen but he would need
> > >>some specific information from your download. A first approach is to
> > >>inspect the .bin dumpfile generated for debug in Subsurface. Then use
> > >>his dctool executable (If I remember correctly it can do Bluetooth and
> > >>it is extremely flexible) and see if you can trace the pO2 values.
> > >>
> > >>I am not sure this is what you may want to hear, but assume that
> > >>(if you
> > >>want the problem solved) you need to take the initiative. You may
> > >>possibly be the only person in this circle which has a divecan
> > >>Petrel so
> > >>you are in the best position to address the problem.
> > >>
> > >
> > >While I do not pretend anything (of course), regarding your
> > >questions I can
> > >assure you that I made everything I could as end user. I gave
> > >- Shearwater desktop screenshots
> > >- Shearwater xml exported logs
> > >- Subsurface xml logs
> > >- Subsurface bin dumps
> > >- dctool dump files
> > >
> > >My only fault was not filing a bug report on Github to resume
> > >everything in
> > >one place.
> > >I even asked on the list if someone else was using a Shearwater
> > >Petrel ECCR
> > >controller and, maybe experiencing the same behavior. No reply. So
> > >I don't
> > >know if it's my specific unit or not.
> > >BTW I recently updated Petrel firmware to the latest version without
> > >results. While it's possible I'm the only Shearwater ccr user on
> > >this list,
> > >we are speaking of the most common eccr controller on the market
> > >nowadays.
> > >It's used on countless rebreathers not an obscure dive computer
> > >implementation.
> > >
> > >Everything started months ago when I discovered that pO2 samples
> > >reported
> > >by Subsurface were completely different (and wrong) from
> > >Shearwater desktop.
> > >There was a long email thread in which AFAIK no solution was found: my
> > >Petrel is strange.
> > >Maybe I missed something and Jef or Anton modified something. I
> > >don't know
> > >but at some point pO2 samples disappeared from Subsurface hence I
> > >opened
> > >this thread but I'm failing to understand what "default
> > >calibration" means
> > >and why in my logbook I find the same device listed with random
> > >number of
> > >sensors.
> > >I asked again today because because even a "guy you must die!"
> > >reply  it's
> > >ok but I got no replies at all.
> > 
> > Sorry for the lack of response, but for the last few weeks, I was
> > just too busy with non-libdivecomputer related things.
> > 
> > Anyway, the problem is as follows. The shearwater devices record two
> > different things:
> > 
> >1. The average/voted ppO2.
> > 
> >2. The value from each O2 sensor. Unfortunately this value is not
> > the ppO2 value, but the raw millivolt measurement from the sensor.
> > In order to convert this value to a ppO2 value, we need to take into
> > account the calibration values.
> > 
> > Last time I checked, shearwater desktop only shows the average/voted
> > ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2)
> > at all (e.g. no millivolt values nor the converted ppO2).
> > 
> > Now, originally libdivecomputer only reported the average/vote ppO2.
> > Later on we figured out how the sensor calibration worked, and this
> > was replaced with the ppO2 value from the individual sensors. But
> > afterwards we also discovered that some devices (like the one from
> > Davide) don't seem to store the calibration values correctly, and
> > leave them at their default values (2100). I have no idea why this
> > happens. Anyway, because applying those calibration values produces
> > incorrect ppO2 values, I added some code to detect this case and
> > disable the ppO2 from the sensors. Since the average/voted ppO2 was
> > already disabled earlier, that also means you won't get any ppO2
> > values at all anymore.
> > 
> > For those bogus default calibration values, there is not much we can
> > do about that. Without the (correct) calibration values, we simply
> > can't calculate the ppO2 values. So unless the calibration values
> > are for some reason stored elsewhere, and we just don't know about
> > this, we're simply stuck here. Shearwater desktop doesn't show this
> > info, so it's difficult to tell what's going on.
> > 
> > The only part that we can do something about, is restoring the
> > average/voted ppO2 again. That's already on my todo list. But right
> > now the libdivecomputer api doesn't have a way to indicate the type
> > of the 

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Anton Lundin]

On 23 May, 2018 - Jef Driesen wrote:

> On 2018-05-23 14:58, Davide DB wrote:
> >On Wed, May 23, 2018, 12:08 Willem Ferguson
> >
> >wrote:
> >>If this is the case, then the problem should in principle be solvable
> >>and it possibly means that the coding in the dive log is slightly
> >>different from that of the standard Petrel and the Fischer
> >>Petrel 2. The
> >>most knowledgeable person to approach is Jef Driesen but he would need
> >>some specific information from your download. A first approach is to
> >>inspect the .bin dumpfile generated for debug in Subsurface. Then use
> >>his dctool executable (If I remember correctly it can do Bluetooth and
> >>it is extremely flexible) and see if you can trace the pO2 values.
> >>
> >>I am not sure this is what you may want to hear, but assume that
> >>(if you
> >>want the problem solved) you need to take the initiative. You may
> >>possibly be the only person in this circle which has a divecan
> >>Petrel so
> >>you are in the best position to address the problem.
> >>
> >
> >While I do not pretend anything (of course), regarding your
> >questions I can
> >assure you that I made everything I could as end user. I gave
> >- Shearwater desktop screenshots
> >- Shearwater xml exported logs
> >- Subsurface xml logs
> >- Subsurface bin dumps
> >- dctool dump files
> >
> >My only fault was not filing a bug report on Github to resume
> >everything in
> >one place.
> >I even asked on the list if someone else was using a Shearwater
> >Petrel ECCR
> >controller and, maybe experiencing the same behavior. No reply. So
> >I don't
> >know if it's my specific unit or not.
> >BTW I recently updated Petrel firmware to the latest version without
> >results. While it's possible I'm the only Shearwater ccr user on
> >this list,
> >we are speaking of the most common eccr controller on the market
> >nowadays.
> >It's used on countless rebreathers not an obscure dive computer
> >implementation.
> >
> >Everything started months ago when I discovered that pO2 samples
> >reported
> >by Subsurface were completely different (and wrong) from
> >Shearwater desktop.
> >There was a long email thread in which AFAIK no solution was found: my
> >Petrel is strange.
> >Maybe I missed something and Jef or Anton modified something. I
> >don't know
> >but at some point pO2 samples disappeared from Subsurface hence I
> >opened
> >this thread but I'm failing to understand what "default
> >calibration" means
> >and why in my logbook I find the same device listed with random
> >number of
> >sensors.
> >I asked again today because because even a "guy you must die!"
> >reply  it's
> >ok but I got no replies at all.
> 
> Sorry for the lack of response, but for the last few weeks, I was
> just too busy with non-libdivecomputer related things.
> 
> Anyway, the problem is as follows. The shearwater devices record two
> different things:
> 
>1. The average/voted ppO2.
> 
>2. The value from each O2 sensor. Unfortunately this value is not
> the ppO2 value, but the raw millivolt measurement from the sensor.
> In order to convert this value to a ppO2 value, we need to take into
> account the calibration values.
> 
> Last time I checked, shearwater desktop only shows the average/voted
> ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2)
> at all (e.g. no millivolt values nor the converted ppO2).
> 
> Now, originally libdivecomputer only reported the average/vote ppO2.
> Later on we figured out how the sensor calibration worked, and this
> was replaced with the ppO2 value from the individual sensors. But
> afterwards we also discovered that some devices (like the one from
> Davide) don't seem to store the calibration values correctly, and
> leave them at their default values (2100). I have no idea why this
> happens. Anyway, because applying those calibration values produces
> incorrect ppO2 values, I added some code to detect this case and
> disable the ppO2 from the sensors. Since the average/voted ppO2 was
> already disabled earlier, that also means you won't get any ppO2
> values at all anymore.
> 
> For those bogus default calibration values, there is not much we can
> do about that. Without the (correct) calibration values, we simply
> can't calculate the ppO2 values. So unless the calibration values
> are for some reason stored elsewhere, and we just don't know about
> this, we're simply stuck here. Shearwater desktop doesn't show this
> info, so it's difficult to tell what's going on.
> 
> The only part that we can do something about, is restoring the
> average/voted ppO2 again. That's already on my todo list. But right
> now the libdivecomputer api doesn't have a way to indicate the type
> of the ppO2 value (e.g. average/voted or from an individual sensor),
> so that would cause confusing. So this will require some (backwards
> incompatible) changes, and that's why it's not done yet.

The simple solution is to just emit the average/voted ppO2 when 

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Aaron Scheiner]

I have a JJ CCR (2017 CE model) with a Petrel 2 DiveCAN computer attached.

I do all my downloads using the Android app (I'm on the beta channel) and I
mostly view the data on Linux. I never use the Shearwater desktop
application. I haven't noticed any discrepancies in the data so far.

I'm hoping to dive this weekend, I'll revert back with additional feedback
once I've dived.

Sorry for not responding sooner.

Aaron


On Wed, May 23, 2018 at 4:22 PM, Jef Driesen 
wrote:

> On 2018-05-23 14:58, Davide DB wrote:
>
>> On Wed, May 23, 2018, 12:08 Willem Ferguson <
>> willemfergu...@zoology.up.ac.za>
>> wrote:
>>
>>> If this is the case, then the problem should in principle be solvable
>>> and it possibly means that the coding in the dive log is slightly
>>> different from that of the standard Petrel and the Fischer Petrel 2. The
>>> most knowledgeable person to approach is Jef Driesen but he would need
>>> some specific information from your download. A first approach is to
>>> inspect the .bin dumpfile generated for debug in Subsurface. Then use
>>> his dctool executable (If I remember correctly it can do Bluetooth and
>>> it is extremely flexible) and see if you can trace the pO2 values.
>>>
>>> I am not sure this is what you may want to hear, but assume that (if you
>>> want the problem solved) you need to take the initiative. You may
>>> possibly be the only person in this circle which has a divecan Petrel so
>>> you are in the best position to address the problem.
>>>
>>>
>> While I do not pretend anything (of course), regarding your questions I
>> can
>> assure you that I made everything I could as end user. I gave
>> - Shearwater desktop screenshots
>> - Shearwater xml exported logs
>> - Subsurface xml logs
>> - Subsurface bin dumps
>> - dctool dump files
>>
>> My only fault was not filing a bug report on Github to resume everything
>> in
>> one place.
>> I even asked on the list if someone else was using a Shearwater Petrel
>> ECCR
>> controller and, maybe experiencing the same behavior. No reply. So I don't
>> know if it's my specific unit or not.
>> BTW I recently updated Petrel firmware to the latest version without
>> results. While it's possible I'm the only Shearwater ccr user on this
>> list,
>> we are speaking of the most common eccr controller on the market nowadays.
>> It's used on countless rebreathers not an obscure dive computer
>> implementation.
>>
>> Everything started months ago when I discovered that pO2 samples reported
>> by Subsurface were completely different (and wrong) from Shearwater
>> desktop.
>> There was a long email thread in which AFAIK no solution was found: my
>> Petrel is strange.
>> Maybe I missed something and Jef or Anton modified something. I don't know
>> but at some point pO2 samples disappeared from Subsurface hence I opened
>> this thread but I'm failing to understand what "default calibration" means
>> and why in my logbook I find the same device listed with random number of
>> sensors.
>> I asked again today because because even a "guy you must die!" reply  it's
>> ok but I got no replies at all.
>>
>
> Sorry for the lack of response, but for the last few weeks, I was just too
> busy with non-libdivecomputer related things.
>
> Anyway, the problem is as follows. The shearwater devices record two
> different things:
>
>1. The average/voted ppO2.
>
>2. The value from each O2 sensor. Unfortunately this value is not the
> ppO2 value, but the raw millivolt measurement from the sensor. In order to
> convert this value to a ppO2 value, we need to take into account the
> calibration values.
>
> Last time I checked, shearwater desktop only shows the average/voted ppO2
> (#1). It doesn't show the individual ppO2 from each sensor (#2) at all
> (e.g. no millivolt values nor the converted ppO2).
>
> Now, originally libdivecomputer only reported the average/vote ppO2. Later
> on we figured out how the sensor calibration worked, and this was replaced
> with the ppO2 value from the individual sensors. But afterwards we also
> discovered that some devices (like the one from Davide) don't seem to store
> the calibration values correctly, and leave them at their default values
> (2100). I have no idea why this happens. Anyway, because applying those
> calibration values produces incorrect ppO2 values, I added some code to
> detect this case and disable the ppO2 from the sensors. Since the
> average/voted ppO2 was already disabled earlier, that also means you won't
> get any ppO2 values at all anymore.
>
> For those bogus default calibration values, there is not much we can do
> about that. Without the (correct) calibration values, we simply can't
> calculate the ppO2 values. So unless the calibration values are for some
> reason stored elsewhere, and we just don't know about this, we're simply
> stuck here. Shearwater desktop doesn't show this info, so it's difficult to
> tell what's going on.
>
> The only part that we can do something about, 

Re: Hashing videos

[Robert Helling]

Hi,

> On 23. May 2018, at 15:23, Berthold Stoeger  
> wrote:
> 
> I fear that any such change would not be backwards-compatible with the current
> hashes. What we could do is for <10 MB files hash all and for >10 MB hash
> filesize + metadata or some such scheme. I hope the <10 MB rule would catch
> nearly all current pictures (we're currently not supporting RAW images, are
> we?).

I don’t think backwards compatibility is any problem at all: At worst, with a 
new version of hashes we get some cache misses and have to once load the actual 
file. So startup is slower when first running a new version.

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

Re: Hashing videos

[Robert Helling]

Hi,

> On 23. May 2018, at 15:23, Berthold Stoeger  
> wrote:
> 
> Under which circumstances do we note that the file changed? The only way I
> currently know of is when the thumbnail is recalculated.

that was at least intended. As I said, I introduced the hashes originally as an 
abstraction of filename/path in order to be able to show the log on different 
machines (including different OSs with different path conventions) as long as 
the files are in some form locally available. So when loading via the hash 
(meaning: from the hash we would infer the actual filename) we would still 
compute the hash of the file that was loaded and update the hash accordingly in 
the log.

It was only later that the hash was also used as a key to coached thumbnails.

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Jef Driesen]

On 2018-05-23 14:58, Davide DB wrote:
On Wed, May 23, 2018, 12:08 Willem Ferguson 


wrote:

If this is the case, then the problem should in principle be solvable
and it possibly means that the coding in the dive log is slightly
different from that of the standard Petrel and the Fischer Petrel 2. 
The

most knowledgeable person to approach is Jef Driesen but he would need
some specific information from your download. A first approach is to
inspect the .bin dumpfile generated for debug in Subsurface. Then use
his dctool executable (If I remember correctly it can do Bluetooth and
it is extremely flexible) and see if you can trace the pO2 values.

I am not sure this is what you may want to hear, but assume that (if 
you

want the problem solved) you need to take the initiative. You may
possibly be the only person in this circle which has a divecan Petrel 
so

you are in the best position to address the problem.



While I do not pretend anything (of course), regarding your questions I 
can

assure you that I made everything I could as end user. I gave
- Shearwater desktop screenshots
- Shearwater xml exported logs
- Subsurface xml logs
- Subsurface bin dumps
- dctool dump files

My only fault was not filing a bug report on Github to resume 
everything in

one place.
I even asked on the list if someone else was using a Shearwater Petrel 
ECCR
controller and, maybe experiencing the same behavior. No reply. So I 
don't

know if it's my specific unit or not.
BTW I recently updated Petrel firmware to the latest version without
results. While it's possible I'm the only Shearwater ccr user on this 
list,
we are speaking of the most common eccr controller on the market 
nowadays.

It's used on countless rebreathers not an obscure dive computer
implementation.

Everything started months ago when I discovered that pO2 samples 
reported
by Subsurface were completely different (and wrong) from Shearwater 
desktop.

There was a long email thread in which AFAIK no solution was found: my
Petrel is strange.
Maybe I missed something and Jef or Anton modified something. I don't 
know
but at some point pO2 samples disappeared from Subsurface hence I 
opened
this thread but I'm failing to understand what "default calibration" 
means
and why in my logbook I find the same device listed with random number 
of

sensors.
I asked again today because because even a "guy you must die!" reply  
it's

ok but I got no replies at all.


Sorry for the lack of response, but for the last few weeks, I was just 
too busy with non-libdivecomputer related things.


Anyway, the problem is as follows. The shearwater devices record two 
different things:


   1. The average/voted ppO2.

   2. The value from each O2 sensor. Unfortunately this value is not the 
ppO2 value, but the raw millivolt measurement from the sensor. In order 
to convert this value to a ppO2 value, we need to take into account the 
calibration values.


Last time I checked, shearwater desktop only shows the average/voted 
ppO2 (#1). It doesn't show the individual ppO2 from each sensor (#2) at 
all (e.g. no millivolt values nor the converted ppO2).


Now, originally libdivecomputer only reported the average/vote ppO2. 
Later on we figured out how the sensor calibration worked, and this was 
replaced with the ppO2 value from the individual sensors. But afterwards 
we also discovered that some devices (like the one from Davide) don't 
seem to store the calibration values correctly, and leave them at their 
default values (2100). I have no idea why this happens. Anyway, because 
applying those calibration values produces incorrect ppO2 values, I 
added some code to detect this case and disable the ppO2 from the 
sensors. Since the average/voted ppO2 was already disabled earlier, that 
also means you won't get any ppO2 values at all anymore.


For those bogus default calibration values, there is not much we can do 
about that. Without the (correct) calibration values, we simply can't 
calculate the ppO2 values. So unless the calibration values are for some 
reason stored elsewhere, and we just don't know about this, we're simply 
stuck here. Shearwater desktop doesn't show this info, so it's difficult 
to tell what's going on.


The only part that we can do something about, is restoring the 
average/voted ppO2 again. That's already on my todo list. But right now 
the libdivecomputer api doesn't have a way to indicate the type of the 
ppO2 value (e.g. average/voted or from an individual sensor), so that 
would cause confusing. So this will require some (backwards 
incompatible) changes, and that's why it's not done yet.


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

Re: Segfault with Qt-5.11.0

[Thiago Macieira]

On Wednesday, 23 May 2018 05:08:58 -03 Gaetan Bisson wrote:
> Any ideas how to debug this?

Can you valgrind? Without debug symbols in Qt it may be a little difficult to 
make sense of what we're seeing, but it might help.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



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

Qt 5.11 released -- QSettings can't save on Android

[Thiago Macieira]

You may want to wait for 5.11.1 or apply the fix[1].

The reason is we're using O_TMPFILE for temporary files now, but the solution 
to materialise the file suggested in the man page[2]

  char path[PATH_MAX];
  fd = open("/path/to/dir", O_TMPFILE | O_RDWR,
  S_IRUSR | S_IWUSR);

  /* File I/O on 'fd'... */

  snprintf(path, PATH_MAX,  "/proc/self/fd/%d", fd);
  linkat(AT_FDCWD, path, AT_FDCWD, "/path/for/file",
  AT_SYMLINK_FOLLOW);

fails because Android security permissions block the link(2) and linkat(2) 
system calls. Since you can't have nice things on Android, I've disabled the 
O_TMPFILE support as well as the rename-overwrite-race-prevention one 
(renameat(2) system call also blocked and can't use link(2)).

statx(2) is also blocked, so you can't get file birth times either.

[1] http://code.qt.io/cgit/qt/qtbase.git/commit/?
id=f86fbc45667528ac9a496d1476bd139f26b3b5bc
[2] http://man7.org/linux/man-pages/man2/open.2.html
-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center



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

Re: Hashing videos

[Berthold Stoeger]

Hi Robert,

On Mittwoch, 23. Mai 2018 10:01:20 CEST Robert Helling wrote:
> Hi,
> 
> > On 23. May 2018, at 07:22, Berthold Stoeger 
> > wrote:
> > 
> > 1) They have the same filename (modulo path and case)
> > 2) They have the same length
> > 3) They have the same meta-data in the case of JPEG
> > Finding two different pictures fulfilling 1-3 must be very bad luck. We
> > currently don't store file-length, but that can be trivially rectified
> > when
> > opening an old log.
> 
> we originally introduced the hashing to make the „find images“ thing
> possible so you don’t have to preserve paths (and filename conventions)
> between different computers. On the other hand, we want to notice when the
> user changed the image (for example by photoshopping, so I guess we have to
> take the content into account).

Under which circumstances do we note that the file changed? The only way I 
currently know of is when the thumbnail is recalculated.

> So my choice would be: Completely ignore filename and path, but maybe take
> into account length and creation date. I don’t have a lot of experience but
> why not hash 1MB of data after seeking to 30% of file size? I would guess
> that is a pretty good test. Or maybe there is an easy way to take internal
> meta date into account as well?

I fear that any such change would not be backwards-compatible with the current 
hashes. What we could do is for <10 MB files hash all and for >10 MB hash 
filesize + metadata or some such scheme. I hope the <10 MB rule would catch 
nearly all current pictures (we're currently not supporting RAW images, are 
we?).

I think a combination of file-length + meta-data would in principle be good 
enough for most cases. For PNGs we already get the created time-stamp as a 
replacement for the missing metadata. But unfortunately, I was wrong in a 
previous mail: We're currently not saving the metadata timestamps - we only 
save an "offset", which may be changed by drag to the profile. :(

One fundamental problem with the metadata is of course that we might change 
the metadata extractor in the future to e.g. support XMP, which would 
invalidate all old stored metadata.

Dirk, any opinion?

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

On Wed, May 23, 2018, 12:08 Willem Ferguson 
wrote:

Hi Willem,

Thank you for the kind reply. I will try to explain me again


> Davide,
>
> Does the correct pO2 show on the Shearwater download software (i.e. the
> Shearwater Desktop)?. This means that the data are correctly reported,
> not a default calibration value as currently with Subsurface.
>
>
Yes,
Everything is ok using the Shearwater software to download dives.
pO2 samples are there and they are correct. I know it for sure because in a
couple of dives I had the time to make oxygen and diluent flushes during my
long deco taking note of dive time and values.
Later I could find those values on Shearwater desktop.


> If this is the case, then the problem should in principle be solvable
> and it possibly means that the coding in the dive log is slightly
> different from that of the standard Petrel and the Fischer Petrel 2. The
> most knowledgeable person to approach is Jef Driesen but he would need
> some specific information from your download. A first approach is to
> inspect the .bin dumpfile generated for debug in Subsurface. Then use
> his dctool executable (If I remember correctly it can do Bluetooth and
> it is extremely flexible) and see if you can trace the pO2 values.
>
> I am not sure this is what you may want to hear, but assume that (if you
> want the problem solved) you need to take the initiative. You may
> possibly be the only person in this circle which has a divecan Petrel so
> you are in the best position to address the problem.
>

While I do not pretend anything (of course), regarding your questions I can
assure you that I made everything I could as end user. I gave
- Shearwater desktop screenshots
- Shearwater xml exported logs
- Subsurface xml logs
- Subsurface bin dumps
- dctool dump files

My only fault was not filing a bug report on Github to resume everything in
one place.
I even asked on the list if someone else was using a Shearwater Petrel ECCR
controller and, maybe experiencing the same behavior. No reply. So I don't
know if it's my specific unit or not.
BTW I recently updated Petrel firmware to the latest version without
results. While it's possible I'm the only Shearwater ccr user on this list,
we are speaking of the most common eccr controller on the market nowadays.
It's used on countless rebreathers not an obscure dive computer
implementation.

Everything started months ago when I discovered that pO2 samples reported
by Subsurface were completely different (and wrong) from Shearwater desktop.
There was a long email thread in which AFAIK no solution was found: my
Petrel is strange.
Maybe I missed something and Jef or Anton modified something. I don't know
but at some point pO2 samples disappeared from Subsurface hence I opened
this thread but I'm failing to understand what "default calibration" means
and why in my logbook I find the same device listed with random number of
sensors.
I asked again today because because even a "guy you must die!" reply  it's
ok but I got no replies at all.

Bye

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Willem Ferguson]

Davide,

I forgot to mention that my understanding is that the Petrel provides a 
voltage, not a pO2 value and that this voltage is converted to a pO2 
value in the Shearwater Desktop or in Subsurface. You possibly may have 
to find the calibration value(s) as well as the voltages in order to 
calulate the pO2.

Kind regards,
willem


--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Willem Ferguson]

On 23/05/2018 11:01, Davide DB wrote:

Hi guys,

Is there any chance that one day it will be possible to see O2 sample on a
CCR dive?

--
Davide


Davide,

Does the correct pO2 show on the Shearwater download software (i.e. the 
Shearwater Desktop)?. This means that the data are correctly reported, 
not a default calibration value as currently with Subsurface.


If this is the case, then the problem should in principle be solvable 
and it possibly means that the coding in the dive log is slightly 
different from that of the standard Petrel and the Fischer Petrel 2. The 
most knowledgeable person to approach is Jef Driesen but he would need 
some specific information from your download. A first approach is to 
inspect the .bin dumpfile generated for debug in Subsurface. Then use 
his dctool executable (If I remember correctly it can do Bluetooth and 
it is extremely flexible) and see if you can trace the pO2 values.


I am not sure this is what you may want to hear, but assume that (if you 
want the problem solved) you need to take the initiative. You may 
possibly be the only person in this circle which has a divecan Petrel so 
you are in the best position to address the problem.


Kind regards,

willem



--
This message and attachments are subject to a disclaimer.

Please refer to 
http://upnet.up.ac.za/services/it/documentation/docs/004167.pdf 
 for
full 
details.

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

Re: Missing pO2 samples from CCR download [was: 4.7.8: a couple of questions]

[Davide DB]

Hi guys,

Is there any chance that one day it will be possible to see O2 sample on a
CCR dive?
On Thu, 10 May 2018 at 22:48, Davide DB  wrote:

> On Thu, 3 May 2018 at 21:39, Davide DB  wrote:

> > On Thu, 3 May 2018 at 18:52, Anton Lundin  wrote:

> >> On 03 May, 2018 - Davide DB wrote:

> >> > On Thu, 3 May 2018 at 13:15, Anton Lundin  wrote:
> >> >
> >> > > On 03 May, 2018 - Davide DB wrote:
> >> > >
> >> > > > On Wed, 2 May 2018 at 11:04, Anton Lundin 
> wrote:
> >> > > >
> >> > > > >
> >> > > > > Try to download them into a fresh logbook with the current
> desktop
> >> > > > > version, to see what's happens then.
> >> > > > >
> >> > > >
> >> > > > I've just downloaded my dives on a fresh Win10 4.7.8
installation.
> >> > > > As usual after few dives my Petrel quits with "error sending
packet
> >> > > error".
> >> > > > I saved some of them anyway and PO2 values are missing.
> >> > > > This is how the petrel controller is recognized. File is
attached.
> >> > > >
> >> > > >  >> > > > diveid='2e7067fb' dctype='CCR'>
> >> > > >
> >> > > > There's no mention of O2 sensor.
> >> > > >
> >> > > > These are all different pertel descriptions of the very same dive
> >> > > computer
> >> > > > I found in my original logbook
> >> > > >
> >> > > >  >> > > > diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
> >> > > >  >> > > > diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
> >> > > >  >> > > > diveid='a6e05a10' dctype='CCR'>
> >> > > >  >> > > > diveid='3db24900' dctype='CCR'>
> >> > > >
> >> > > > Were pO2 samples download removed?
> >> > >
> >> > > This is probably because we can't find any calibration values in
your
> >> > > computer. Did you get a warning:
> >> > > "Disabled all O2 sensors due to a default calibration value." ?
> >> > >
> >> > > I think the code should fall back to the sensor average po2 when we
> >> > > won't get calibration values for the sensors, but we're not doing
> that
> >> > > right now.
> >> > >
> >> >
> >> > Anton,
> >> >
> >> > I'm not crazy enough to dive a rebreather without a proper
calibration.
> >> > Everything is ok on my unit. Cells are new and get calibrated before
> every
> >> > dive.

> >> Shure. The computer is probably properly calibrated, but the
> >> calibration values found in the memory of the computer are the default
> >> ones. Without those we can't convert the mV values to po2 values.

> >> The cal values might be there somewhere, but we don't know where.

> >> We can't emit the raw mV values, because neither libdivecomputer nor
> >> subsurface supports mV values.

> >> > I tried to download again from Shearwater desktop and everything is
> there:
> >> > pO2 and mV samples. I've never updated my Petrel since we found that
> >> > Subsurface pO2 values were completely wrong so I guess it should be
> some
> >> > bug arose lately.
> >> > It's sad nobody else (ccr users) replied to my feedback request when
I
> >> > noted the pO2 discrepancy. I cannot believe I'm the only one on this
> list
> >> > using a ccr unit whit a divecan shearwater controller.
> >> >  When I realized pO2 were missing I thought it was something related
> to the
> >> > mobile download but it's not.
> >> >
> >> > I would do a full Subsurface download but I drained another battery
> but I
> >> > do not have a new one around ATM.

> >> We should at least emit the per sample average, when we can't emit the
> >> individual sensor values.

> >> Best would be if we could emit both the "true" average po2 and the
> >> individual sensor values. Unfortunately the interface doesn't support
> >> that distinction.


> > I changed battery and downloaded again with subsurface 4.7.8 desktop
> saving the libdivecomputer log file.
> > I quit the download before getting errors and draining my battery.
> > At the end of the libdivecomputer file I find:

> > WARNING: Disabled all O2 sensors due to a default calibration value. [in

/home/travis/build/Subsurface-divelog/subsurface/libdivecomputer/src/shearwater_predator_parser.c:503
> (shearwater_predator_parser_cache)]
> > INFO: Write: size=9, data=FF0105002E902000C0

> > Exactly the problem mentioned by Anton.

> > Could someone explain me what does it means?
> > Is it a way to avoid displaying wrong pO2 samples due to the previous
> problem?
> > What can I do? Is it my fault? Is my Petrel defective?

> > Why in my logbook I find 4 different computer names with different
> attributes if my unit is always the same?

> > 
> diveid='3db7eb77' dctype='CCR' no_o2sensors='1'>
> > 
> diveid='52d4ba3e' dctype='CCR' no_o2sensors='3'>
> > 
> diveid='a6e05a10' dctype='CCR'>
> > 
> diveid='3db24900' dctype='CCR'>

> > Are those differences due to subsurface history reason?

> > Thank you in advance

> > --
> > Davide
> > https://vimeo.com/bocio/videos



> Thank you guys

> --
> Davide



-- 
Davide
https://vimeo.com/bocio/videos
___

Re: SubSurface Mobile and OTG

[Guillaume Gardet]

Hi,


Le 23/05/2018 à 07:29, Miika Turkia a écrit :

This does work for some divecomputers, depending on the ftdi chip that is used 
on the cable. We also have some trouble with Android OS as some newer Android 
versions prevent us from accessing the USB devices. What versions of DC, cable 
(the serial chip), phone and Android you are using? (I have used OTG on Nexus 7 
tablet and Suunto Vyper Air DC successfully, don't remember the Android version 
on the tablet.)


Does it still work? Because Vyper Air on a Nexus 7 fails for me. :(

See: 
http://lists.subsurface-divelog.org/pipermail/subsurface/2018-May/032015.html

Guillaume



On Wed, May 23, 2018 at 8:15 AM, Thomas Fänge > wrote:

Hi!

First, thanks all for you effort and the great and useful application!

I'm connecting my dive computer to my Linux laptop, and that works perfect.
But, wouldn't it be possible to do that on the SubSurface Mobile (Android) 
app too?

I have a "watertight" Sony phone, and I use a USB On-The-Go (OTG) cable to 
use e.g. a mouse or external keyboard, so should it not then be possible to use 
USB-communication from the SubSurface app too, instead of only a Bluetooth connection? 
This would enable me to only bring the phone while travelling, even on the boat or shore 
and download my dives, getting the current position etc. without worrying if the phone 
gets wet or not.

Today, when I connect the dive computer to the phone with the OTG cable, I 
can see on the leds on the interface cable that the connection is made to the 
phone, but that interface (USB) never turns up as an option in the SubSurface 
dive computer menu - only Bluetooth is available there.

Best regards,
Thomas


___
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


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

Segfault with Qt-5.11.0

[Gaetan Bisson]

Dear all,

I'm getting a segfault when running Subsurface with Qt-5.11. It occurs
with both an old binary compiled against Qt-5.10 and a freshly rebuilt
binary. Note that building against Qt-5.11 requires fixing a couple of
headers, but that's unrelated:

https://github.com/Subsurface-divelog/subsurface/pull/1317

The segfault occurs whenever the dive list is nonempty. With a new
profile, just click on "Log" then "Add Dive" and then "Apply Changes" to
trigger it. Here's a backtrace:


Thread 1 "subsurface" received signal SIGSEGV, Segmentation fault.
0x705aa4d2 in QSortFilterProxyModel::parent(QModelIndex const&) const 
() from /usr/lib/libQt5Core.so.5
(gdb) bt
#0  0x705aa4d2 in QSortFilterProxyModel::parent(QModelIndex const&) 
const () at /usr/lib/libQt5Core.so.5
#1  0x7291f60a in QTreeView::drawRow(QPainter*, QStyleOptionViewItem 
const&, QModelIndex const&) const () at /usr/lib/libQt5Widgets.so.5
#2  0x72924e7f in QTreeView::drawTree(QPainter*, QRegion const&) const 
() at /usr/lib/libQt5Widgets.so.5
#3  0x729299f8 in QTreeView::paintEvent(QPaintEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#4  0x726a0058 in QWidget::event(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#5  0x727467df in QFrame::event(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#6  0x728c0b84 in QAbstractItemView::viewportEvent(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#7  0x7292aa3c in QTreeView::viewportEvent(QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#8  0x705cf8db in 
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject*, QEvent*) () at 
/usr/lib/libQt5Core.so.5
#9  0x72660974 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /usr/lib/libQt5Widgets.so.5
#10 0x7266825b in QApplication::notify(QObject*, QEvent*) () at 
/usr/lib/libQt5Widgets.so.5
#11 0x705cfbc9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /usr/lib/libQt5Core.so.5
#12 0x726989bc in QWidgetPrivate::sendPaintEvent(QRegion const&) () at 
/usr/lib/libQt5Widgets.so.5
#13 0x72699141 in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#14 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#15 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#16 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#17 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#18 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#19 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#20 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#21 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#22 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#23 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#24 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#25 0x72699d14 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, int, QPainter*, 
QWidgetBackingStore*) () at /usr/lib/libQt5Widgets.so.5
#26 0x72698f0d in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, int, QPainter*, QWidgetBackingStore*) ()
at /usr/lib/libQt5Widgets.so.5
#27 0x72699e2e in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList 

Re: Hashing videos

[Robert Helling]

Hi,

> On 23. May 2018, at 07:22, Berthold Stoeger  
> wrote:
> 
> 1) They have the same filename (modulo path and case)
> 2) They have the same length
> 3) They have the same meta-data in the case of JPEG
> Finding two different pictures fulfilling 1-3 must be very bad luck. We
> currently don't store file-length, but that can be trivially rectified when
> opening an old log.

we originally introduced the hashing to make the „find images“ thing possible 
so you don’t have to preserve paths (and filename conventions) between 
different computers. On the other hand, we want to notice when the user changed 
the image (for example by photoshopping, so I guess we have to take the content 
into account).

So my choice would be: Completely ignore filename and path, but maybe take into 
account length and creation date. I don’t have a lot of experience but why not 
hash 1MB of data after seeking to 30% of file size? I would guess that is a 
pretty good test. Or maybe there is an easy way to take internal meta date into 
account as well?


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

Re: SubSurface Mobile and OTG

[Thomas Fänge]

Hi Miika,

That sounds promising!

I use a Mares Puck Pro with the USB-cable (don't have it here right now so
I can't check the version of it nor the ftdi chip). And I use an Sony
Xperia XZ2 with the O release of Android.
But if you say that the support is there, then I could get the logs from
the phone and see what actually happens.
I could also try on an older Xperia Tablet (Z3 or Z4) and see if they work
(with an older Android cookie).

/Thomas

ons 23 maj 2018 kl 07:29 skrev Miika Turkia :

> This does work for some divecomputers, depending on the ftdi chip that is
> used on the cable. We also have some trouble with Android OS as some newer
> Android versions prevent us from accessing the USB devices. What versions
> of DC, cable (the serial chip), phone and Android you are using? (I have
> used OTG on Nexus 7 tablet and Suunto Vyper Air DC successfully, don't
> remember the Android version on the tablet.)
>
> On Wed, May 23, 2018 at 8:15 AM, Thomas Fänge 
> wrote:
>
>> Hi!
>>
>> First, thanks all for you effort and the great and useful application!
>>
>> I'm connecting my dive computer to my Linux laptop, and that works
>> perfect.
>> But, wouldn't it be possible to do that on the SubSurface Mobile
>> (Android) app too?
>>
>> I have a "watertight" Sony phone, and I use a USB On-The-Go (OTG) cable
>> to use e.g. a mouse or external keyboard, so should it not then be possible
>> to use USB-communication from the SubSurface app too, instead of only a
>> Bluetooth connection? This would enable me to only bring the phone while
>> travelling, even on the boat or shore and download my dives, getting the
>> current position etc. without worrying if the phone gets wet or not.
>>
>> Today, when I connect the dive computer to the phone with the OTG cable,
>> I can see on the leds on the interface cable that the connection is made to
>> the phone, but that interface (USB) never turns up as an option in the
>> SubSurface dive computer menu - only Bluetooth is available there.
>>
>> Best regards,
>> Thomas
>>
>>
>> ___
>> 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