From b62f160dd56121a904fca380ba5589d30312b7c9 Mon Sep 17 00:00:00 2001 From: Jef Driesen Date: Tue, 13 Mar 2018 21:17:45 +0100 Subject: [PATCH] Workaround for an OSTC4 issue I received a bug report complaining that the most recent dives did not get downloaded. It turns out that the internal dive number in the logbook entries got reset back to zero somehow: Logbook 0: empty ... Logbook 209: empty Logbook 210: 1 Logbook 211: 2 ... Logbook 235: 26 Logbook 236: 27 Logbook 237: 0 Logbook 238: 1 ... Logbook 254: 17 Logbook 255: 18 This confuses the logic to locate the most recent dive. Because that logic assumes that the entry with the highest internal dive number is always the most recent dive, it finds logbook entry #236 instead of the correct entry #255. Now, when processing the logbook entries backwards, it stops at those empty entries, and thus never reaches then newest entries #237 to #255. The workaround is based on the fact that the OSTC4, unlike the other hwos based models, already re-orders the logbook entries and always sends the most recent logbook entry last. So we can ignore the dive number and simply use the last non-empty entry. --- src/hw_ostc3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/hw_ostc3.c b/src/hw_ostc3.c index 5dec754..9a6c731 100644 --- a/src/hw_ostc3.c +++ b/src/hw_ostc3.c @@ -695,7 +695,7 @@ hw_ostc3_device_foreach (dc_device_t *abstract, dc_dive_callback_t callback, voi // Get the internal dive number. unsigned int current = array_uint16_le (header + offset + logbook->number); - if (current > maximum) { + if (current > maximum || device->hardware == OSTC4) { maximum = current; latest = i; }