Question 1

なぜタイムラインカレンダーは、バージョン1.7.0にアップデートした後に追加されたアクティビティに対して緑の日を表示しないのですか？

Accepted Answer

このバグが修正されたバージョン1.7.11にアップデートしてください。この問題により、timeline calendarがローカル時間ではなくUTC時間を使用するようになり、新しいポイントの緑色のインジケーターが表示されなくなりました。すぐにアップデートできない場合は、一時的な回避策としてタイムゾーン設定を確認してください。

Question 2

Maplibre 1.7.1にアップグレードした後、'KeyError in Map::Maplibre#index'と'JWT_SECRET_KEY not found'が発生するのはなぜですか？

Accepted Answer

環境変数 JWT_SECRET_KEY が設定されていません。v1.7.0 以降、JWT シークレットが必要です。Docker 環境で設定してください: `-e JWT_SECRET_KEY=your_secret_key` を追加するか、docker-compose に `environment: JWT_SECRET_KEY: your_secret_key` を含めてください。安全なランダム文字列（例: `openssl rand -hex 32`）を使用してください。変数を設定した後、コンテナを再起動してください。

Question 3

Prometheus/Mimir の 'duplicate sample for timestamp' エラーと Dawarich の /metrics における重複シリーズを修正する方法

Accepted Answer

Dawarich をバージョン 1.16.0 にアップグレードしてください。1.15.3 までのバージョンでは、メトリクス集約ロジックがラベルの順序を正規化せずにシリアライズされたラベル文字列を比較していたため、web プロセスと Sidekiq プロセスが同一のラベルセットを異なる順序で出力した場合、区別を示す `process="web"` / `process="sidekiq"` ラベルが付かないまま、重複するシリーズ（主に `activerecord_*` メトリクス）が生成されていました。このため、Grafana Alloy/Prometheus 経由でスクレイピングした際に、Mimir HTTP 400 の `duplicate sample for timestamp` エラーなどの取り込み失敗が発生していました。この修正では、マージ前にラベルセットを正規化します。`freikin/dawarich` イメージを 1.16.0 以降に更新してください。

Question 4

なぜDawarichの年次Insightsの国カウントに国（例：リヒテンシュタイン）が含まれないのですか？

Accepted Answer

これは Dawarich の年次 Insights 集計におけるバグ(影響を受けるバージョン: 1.11.0)で、`points` テーブルと `stats.toponyms` の両方にその国が存在しているにもかかわらず、年次の訪問国数からその国が除外されてしまう可能性があるというものでした。このバグは Dawarich 1.16.0 で修正されました。解決するには: 1) Dawarich コンテナをバージョン 1.16.0 以降にアップグレードします(例: Docker/Portainer スタックのイメージタグを更新して再デプロイします)。2) Dawarich を開き、**Update Stats** を実行して統計を再計算します。3) Sidekiq ですべての `Stats::CalculatingJob` ジョブが完了するまで待ち、その後 Insights ページを強制的に再読み込み(ハードリフレッシュ)します。事前に次の SQL で基となるデータを確認できます: `SELECT country_name, COUNT(*) FROM points WHERE country_name = 'Liechtenstein' GROUP BY country_name;` — 行が存在する場合、アップグレードと統計の再計算によって、年次の概要にその国が再び表示されるようになります。

Question 5

Dawarichのトラックが複数日にまたがり、GPSポイントが連続的に到着しても分割されないのはなぜですか？

Accepted Answer

これは Dawarich 1.17.0 で修正された既知のバグです。1.17.0 以降にアップグレードしてください。根本原因: `app/services/tracks/segmentation.rb` におけるトラックのセグメンテーションは、時間間隔の閾値（`minutes_between_routes`、例: 30分）のみに依存していました。`haversineDistance()` はキロメートルを返すのに対し UI の値はメートルであるため（単位の不一致）、距離ベースの分割は実質的に無効になっていました。デバイス（例: すべての位置情報更新を転送する Home Assistant、または Google Timeline のインポート）が静止中も含めて継続的に位置を報告する場合、どの間隔も閾値を超えることがないため、トラックは閉じられることがなく、夜間の静止期間を吸収してしまいます（例: 35.9時間 / 153 km の1本のトラック）。アップグレード前の回避策: (1) `Tracks::ParallelGeneratorJob` を `mode: :bulk, chunk_size: 1.day` で使用してトラックを手動で再処理する（部分的な修正で、トラックを日単位で分割します）。(2) トラッカーアプリの報告頻度を下げるか、静止時に更新を一時停止するよう設定して、実際の間隔が発生するようにする。なお、`minutes_between_routes` を下げても効果はありません。ハードコードされた再マージルールが、低い閾値で分割されるものをすべて再結合してしまうためです。アップグレード後は、既存のトラックを再処理して正しいセグメンテーションを再構築してください。

Dawarich

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト