Question 1

Why does the Timeline Calendar not show green days for activities added after updating to version 1.7.0?

Accepted Answer

Update to version 1.7.11 where this bug is fixed. The issue caused the timeline calendar to use UTC time instead of local time, leading to missing green indicators for new points. If updating immediately isn't possible, check your timezone settings as a temporary workaround.

Question 2

Why do I get 'KeyError in Map::Maplibre#index' and 'JWT_SECRET_KEY not found' after upgrading to Maplibre 1.7.1?

Accepted Answer

The JWT_SECRET_KEY environment variable is missing. Starting from v1.7.0, a JWT secret is required. Set it in your Docker environment: add `-e JWT_SECRET_KEY=your_secret_key` or include `environment: JWT_SECRET_KEY: your_secret_key` in docker-compose. Use a secure random string (e.g., `openssl rand -hex 32`). Restart the container after setting the variable.

Question 3

How to fix 'duplicate sample for timestamp' Prometheus/Mimir errors and duplicate series in Dawarich /metrics?

Accepted Answer

Upgrade Dawarich to version 1.16.0. In versions up to 1.15.3, the metrics aggregation logic compared serialized label strings without normalizing label order, so web and Sidekiq processes emitting identical label sets in different orders produced duplicate series (mainly in `activerecord_*` metrics) without the distinguishing `process="web"` / `process="sidekiq"` label. This caused ingestion failures such as Mimir HTTP 400 `duplicate sample for timestamp` errors when scraping via Grafana Alloy/Prometheus. The fix normalizes label sets before merging; update the `freikin/dawarich` image to 1.16.0 or later.

Question 4

Why is a country (e.g., Liechtenstein) missing from the yearly Insights country count in Dawarich?

Accepted Answer

This was a bug in Dawarich's yearly Insights aggregation (affected version 1.11.0) where a country could be omitted from the yearly visited-country count even though it existed in the `points` table and in `stats.toponyms`. It was fixed in Dawarich 1.16.0. To resolve: 1) Upgrade your Dawarich container to version 1.16.0 or later (e.g., update the image tag in your Docker/Portainer stack and redeploy). 2) Open Dawarich and run **Update Stats** to recalculate statistics. 3) Wait until all `Stats::CalculatingJob` jobs finish in Sidekiq, then hard-refresh the Insights page. You can verify the underlying data beforehand with SQL: `SELECT country_name, COUNT(*) FROM points WHERE country_name = 'Liechtenstein' GROUP BY country_name;` — if rows exist, the upgrade plus stats recalculation will restore the country in the yearly overview.

Question 5

Why do Dawarich tracks span multiple days and never split when GPS points arrive continuously?

Accepted Answer

This is a known bug fixed in Dawarich 1.17.0 — upgrade to 1.17.0 or later. Root cause: track segmentation in `app/services/tracks/segmentation.rb` relied only on the time-gap threshold (`minutes_between_routes`, e.g. 30 min). Distance-based splitting was effectively disabled because `haversineDistance()` returns kilometers while the UI value is in meters (unit mismatch). If your device (e.g. Home Assistant forwarding every location update, or Google Timeline import) reports position continuously — including while stationary — no gap ever exceeds the threshold, so tracks never close and absorb overnight stationary periods (e.g. one 35.9 h / 153 km track). Workarounds before upgrading: (1) manually reprocess tracks with `Tracks::ParallelGeneratorJob` using `mode: :bulk, chunk_size: 1.day` (partial fix, splits tracks daily); (2) reduce your tracker app's reporting frequency or configure it to pause updates when stationary so real gaps occur. Note that lowering `minutes_between_routes` does NOT help, because a hardcoded re-merge rule recombines anything a lower threshold would split. After upgrading, reprocess existing tracks to rebuild correct segmentation.

Dawarich

Core Features

What It Can't Do

Use Cases

Tags

Getting Started

Similar Projects