4 Commits

Include renames

Author	SHA1	Message	Date
randy	b0c93d10d7	Detect a LiveTrack session ending the moment Garmin confirms it, not 30min later ... Watched the session from the last two commits actually get saved: Garmin updated its `end` field from the future 24h placeholder to within a second of the last point's own time, immediately — much faster than the recency-of-last-point fallback alone would have noticed (that only flips after ACTIVE_WITHIN with no new points, so a just-saved session with a last point seconds old would still read as active for up to 30 more minutes). Now checks end-already-in-the-past first (authoritative and near instant when Garmin has set it), falling back to point recency only when end still shows the future placeholder — the case an abandoned, never-saved session never updates.	2026-09-20 16:55:57 +02:00
randy	3106f8c103	Draw a LiveTrack session's planned course alongside the actual track ... Garmin's own LiveTrack page already shows both when the activity was started from a saved course — the session payload carries the course's geoPoints right alongside the track points (LiveTrackClient found it nested under the same React Query cache the session/points come from). Rendered as a second, dashed LineString distinct from the actual track's own line ("kind": "actual" vs "planned" on each GeoJSON feature) — muted gray rather than matching Garmin's own purple-for- planned, since this app's actual track is already purple and reusing it would make the two indistinguishable.	2026-09-20 16:54:24 +02:00
randy	5d86cb1d04	Detect a live LiveTrack session from its last point, not session["end"] ... session["end"].nil? was the active signal since this was first built, on the assumption Garmin leaves it unset until the activity actually stops. Checked directly against a real still-recording session today (2026-09-20): end was already non-nil, set to exactly start + 24h — the share link's own expiry, not an end time — so every currently-active session was showing as "Ended". A genuinely ended session's end does hold its real end time (confirmed against the 2026-09-06 session this was originally, and only, verified against), which is what made the bug easy to miss. Recency of the last track point is a directly-observable signal instead of reverse-engineering what a given `end` value means: Garmin posts one roughly every postTrackPointFrequency seconds (~15, observed) while genuinely still recording.	2026-09-20 16:42:52 +02:00
randy	cd4eef342b	Add a persisted test suite ... `bundle exec rake test` (minitest, a default gem but pinned in Gemfile for reproducibility) now covers what ad-hoc scripts kept re-verifying by hand during development: Gpx/Fit/TrackStats parsing, GpxStore/LiveTrackStore file/TTL logic, LiveTrackClient's payload parsing, and app.rb's routes end to end via Rack::MockRequest. MAPTOOL_DATA_DIR (new, app.rb) lets the suite point GPX_STORE/ LIVETRACK_STORE at a throwaway directory instead of real data/ — without it every run would leave uploaded test files behind. Each lib file's old `if __FILE__ == $0` self-check is now redundant with real tests covering the same ground, so removed rather than kept as a second copy of the same assertions. Wired into ci.yml so it isn't just a local convenience.	2026-09-07 12:46:35 +02:00