Do some cleanup of the code, there might be more of that as I am still
learning the Uemis code
Signed-off-by: glerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- enabled capturing of the original Uemis dive number
- previousely the object_id was passed to dive as dive number
- I am using a workaround (not nice but effective) by parsing the dive_no
out of a copy of inbuf before the object_id is parsed. The reason why is
that the dive_no comes before the object_id hence the normal parsing
would miss it.
Signed-off-by: glerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- changed the uemis_add_string to support a delimiter in parameter 3
- passing each nickname to the parse_tag function appending dive->buddy
with concatentated nicknames separaed by comma
Signed-off-by: glerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- change the way how dive logs are mapped to dive details in
do_uemis_import()
- dives deleted on the Uemis will not be downloaded anymore (added
function uemis_delete_dive_by_diveid)
- change the way the memory consumption was checked to acknowledge
very large files (trying to predic on how many more files fit into
the buffer by calculating an average consumbtion over each
divelogs block)
- minimal design change to support the above
[Dirk Hohndel: refactored one huge commit into smaller pieces]
Signed-off-by: Guido Lerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
But sadly the code then doesn't actually use that return value, so this is
not quite perfect, yet.
[Dirk Hohndel: refactored one huge commit into smaller pieces]
Signed-off-by: Guido Lerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This function is only used in the Uemis downloader, and it got broken when
we switched to using a separate table for the downloaded dives.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This shouldn't change any of the actualy code, except when it comes to
debugging output.
[Dirk Hohndel: refactored one huge commit into smaller pieces]
Signed-off-by: Guido Lerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes the comments line up more nicely and fixes some other random
issues in preparation for the following changes.
[Dirk Hohndel: refactored one huge commit into smaller pieces]
Signed-off-by: Guido Lerch <guido.lerch@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having random uuids seemed like a good idea, but there are several
situations where they really cause problems. One is merging dive file
imports from V2 logfiles. Another is testing such imports.
Instead of making the uuid random we now hash the name and add the
timestamp of the first dive associated with this dive site to the hash
(first in this context is "first encountered" with no guarantee that it is
the chronologically first). This way V2 imports create deterministic uuids
but uuid conflicts are still extremely unlikely, even if the user has
multiple dive sites with the same name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Most of these will likely have no big impact, but it's better not to just
ignore them as they could lead to crashes.
Uemis downloader: if lseek fails, return 0
Uemis downloader: consistently check for failure to open req.txt
Zip file handling: dup could fail
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Free memory returned from parse_mkvi_value()
Free memory returned from printGPSCoords()
Free memory allocated in added_list and removed_list
Free memory allocated when adding suffix to dive site name
Free memory allocated in cache_deco_state()
Free memory allocated in build_filename()
Free memory allocated in get_utf8()
Free memory allocated in alloc_dive()
Free memory allocated as cache but never used
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A complete batch of divelog and dive data takes about 20% of the available
space (depending on how long those dives are). This is a hack and I can
see this potentially going wrong, but the alternative is to be even more
conservative and that has its own set of problems as it causes us to need
more "unplug, wait, plug in again and restart" cycles.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks like a fairly big change but it mostly just moves a block of
code inside an earlier loop and adjust a few variables around it.
The completely broken and insane Uemis download protocol distributes data
across different "databases" on the dive computer. The "divelogs" are
downloaded in batches of 10 (most of the time), and with this change every
time one of those batches is downloaded we straight away get the matching
"dive" entries.
Hopefully this will avoid having the download abort (for lack of space)
before all components are loaded.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This caused us to not read the auxiliary information for up to the last
ten dives that were downloaded from the SDA.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user hits retry from within the download dialog, the dive list
might still be empty but we still have to look for the best point to
restart.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we run out of space in the Uemis filesystem we return an error. The
user could reasonably unplug the SDA, insert it again and then retry to
continue the download (that's what we tell them to do). In that case we
need to make sure we start at the correct dive otherwise the same dives
keep getting downloaded over and over again.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A complete batch of divelog and dive data takes about 20% of the available
space (depending on how long those dives are). This is a hack and I can
see this potentially going wrong, but the alternative is to be even more
conservative and that has its own set of problems as it causes us to need
more "unplug, wait, plug in again and restart" cycles.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This looks like a fairly big change but it mostly just moves a block of
code inside an earlier loop and adjust a few variables around it.
The completely broken and insane Uemis download protocol distributes data
across different "databases" on the dive computer. The "divelogs" are
downloaded in batches of 10 (most of the time), and with this change every
time one of those batches is downloaded we straight away get the matching
"dive" entries.
Hopefully this will avoid having the download abort (for lack of space)
before all components are loaded.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This caused us to not read the auxiliary information for up to the last
ten dives that were downloaded from the SDA.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user hits retry from within the download dialog, the dive list
might still be empty but we still have to look for the best point to
restart.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we run out of space in the Uemis filesystem we return an error. The
user could reasonably unplug the SDA, insert it again and then retry to
continue the download (that's what we tell them to do). In that case we
need to make sure we start at the correct dive otherwise the same dives
keep getting downloaded over and over again.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A well intentioned attempt in commit ff860b3c04 ("uemis-downloader -
resource leaks") to fix resource leaks actually introduced a bug.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We pass a different table to libdivecomputer (and the uemis code) and have
that table filled. And then we simply copy the dives from that table into
the real dive_table when the user accepts the download.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that we pass in the full device_data_t information, we can look at
the "create_private_dive" flag and decide just how to record newly
downloaded dives properly.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Not only does it make it look more like the libdivecomputer downloaders,
but the uemis downloader needs it in order to support all the flags we
have. Notably "download into private trip".
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we can easily decode the start time of the dive that is currently being
parsed (i.e., if the information doesn't happen to straddle a block
boundary) then show that in the dialog's progress bar.
Make the explanatory text before it shorter so there's enough space.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
[Dirk Hohndel: this overlapped with my commit 09e7c61fee ("Consistently
use for_each_dive (and use it correctly)") so I took the
pieces that I had missed]
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
A bit longer, but we had a function named get_dive_by_diveid
and another one named getDiveByDiveid that did completely
different things, it was too easy to hit the wrong one..
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we first get an invalid dive info and then, once we decremented the
offset, get a valid one but for the wrong dive and then try to calculate
the correct offset, we need to keep the existing offset in mind.
What a horrid design. Thanks, UEMIS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
After receiving another report of the Uemis downloader failing I tried to
make it more robust when unexpected things happen. The data structures
returned by the SDA are rather convoluted and not all relationships are
fully understood.
This makes sure we don't try to parse invalid dive entries, we only read
dive entries if we actually got new divelog entries, we only read dive
sites if at least one was referenced and we use a much more patient (and
hopefully, much more robust) algorithm to figure out which dive entry
corresponds to the new divelog entries.
What a pain.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
