Community questions, answered from these docs

Answered here. Discussion #3382, asked 18 August, still open. The asker has a self-hosted instance tracking from the iOS app and found a file of higher-resolution coordinates on their dashcam SD card. They say outright: "I've browsed thru the FAQ and the docs but couldn't get a clear answer."

Yes, sources can be mixed, and two documented behaviours are why:

1. Imports accepts GPX for recorded routes, GeoJSON, OwnTracks .rec, and Dawarich's own export format. If the dashcam file can be converted to GPX or GeoJSON, it imports like anything else.
2. Points are unique per user by coordinates and timestamp. Importing a second source alongside phone tracking does not create duplicates, and re-importing the same file does not either. Denser dashcam points land as additional points on the same routes.

The one thing the docs do not cover: converting a vendor-specific .txt from a dashcam into GPX. That step is on you, and the format varies by device.

Half answered. Discussion #3372, asked 17 August, no replies. A Pro self-hoster can select workouts and import them by hand, and asks two things: does it run automatically, and will workouts collide with normal tracking?

The second half is answered: points are validated for uniqueness on coordinates and timestamp, so a workout that overlaps a period of ordinary tracking will not double up your history. See Imports.

The first half is not documented anywhere on this site. Whether automatic Apple Health import exists, is planned, or is deliberately manual is a question only the maintainer can answer.

Not covered. Discussion #3275, asked 31 July, no replies, with a screenshot of the stuck state.

Trips explains how to create, edit and delete a trip and what the detail page shows. It does not describe what happens in the background when a trip is built, how long it should take, or what to check when it never finishes.

Nearby pages hold pieces of the answer — Prometheus monitoring and the Sidekiq queues described under Imports are where background jobs surface — but nothing joins them up for this symptom. This is a real gap, not a findability problem.

Half answered. Discussion #3160, asked 19 July. Routes show as straight lines between distant points, and standing still all day records nothing.

The straight lines are explainable from the docs: Minutes Between Routes and Meters Between Routes in Settings decide when a gap starts a new route rather than joining two points with a line. Tuning those changes how sparse data is drawn.

What is not documented is the app side — how often the iOS app records, what accuracy mode it uses, and whether it is expected to log anything while stationary. Dawarich for iOS covers installing, connecting and offline buffering, but not tracking frequency.

Answered here, and it takes two pages. Discussion #3158, asked 18 July, still open. The asker concluded ARM64 builds might not exist and offered to help test them.

ARM64 is supported. Hardware requirements states Dawarich runs on AMD64 or ARM64, and the self-hosting introduction carries the note that matters: on an ARM64 server, check the Moving to PostGIS guide for suitable database images.

The error is not about the Dawarich image. It is the database image. Moving to PostGIS gives the replacement by architecture:

Swap the database image in docker-compose.yml and the pull succeeds.

Answered, and the answer is no. Discussion #2968, asked 19 June. The asker wants the numbers from the admin Users screen for a homepage dashboard.

The published API has no admin or all-users endpoint. What exists is scoped to the authenticated user: GET /api/v1/stats returns that user's aggregated totals, and GET /api/v1/users/me returns that user's own record. GET /api/v1/users/exist only checks whether given user IDs exist. See the project's OpenAPI specification.

For an instance-wide dashboard today, the numbers have to come from the database rather than the API.

Answered in part, and the missing part is a recommendation. Discussion #2960, asked 16 June, no replies. Visits are being created several hundred metres after leaving home and before arriving at work, on a 5 km commute.

The knobs are documented. Under Visit Settings in Settings:

Visits and Places explains the nightly job, suggested versus confirmed visits, and how to decline a suggestion so it stops coming back.

Two things are genuinely absent: any recommended value for a short-commute case, and Smart density fill, the setting the asker names, which does not appear anywhere in this documentation.