Skip to content

Personal Statistics Overview #207

Description

@carlhye

MA 2.10 — Synthesized from Marvin/Carl meeting notes, June 5 2026


Problem statement

Users have no visibility into their own listening history within Music Assistant. There's no way to know which artists you play most, how much you've listened across providers, or what genres dominate your listening. This is a missed opportunity to deliver on MA's core emotional promise: "we suggest what makes your home listening experience more personalized." Without a play-history layer, MA cannot personalize anything — it has no signal to work from.

Streaming services like Spotify (Wrapped) have demonstrated that personal listening stats drive both satisfaction and retention. But each service can only show you what you streamed there. MA's open, multi-provider architecture makes it uniquely positioned to show users their full listening picture — across Tidal, Spotify, local files, radio, and everything else — something no individual streaming service can ever offer. This bet builds the foundation (listen-event logging) that makes personalization, recommendations, and a "Year in Music" possible, and in doing so directly delivers on what makes MA emotionally resonant as a product.

Community signals

  • Enhancement: Library stats (eg. artist-, albums,- & trackcounts) — User requests library size stats displayed within the library views, not buried in Settings > About. Includes a Roon-inspired mockup. "For a music collector, it's very satisfying to be able to see what's in your library at any given moment."
  • Statistics and metadata scanning progress page — Requests overall library stats, time-since-last-scan, and background scan visibility. Notes that per-user stats are a dependency: "currently a user sees global library stats, even if they don't have access to all these library items."
  • Play tracking in spotify — User reports MA doesn't report plays back to Spotify, breaking recommendations. Symptom: no global play-history layer exists in MA today.
  • "Scrobble" back to Emby Server — Same pattern: users want plays reported to Emby for their own listening history. Multiple providers, same underlying ask.
  • Smart Playlist filter: "Not played in X days" — Requires the exact same play-history infrastructure as a personal statistics dashboard. High-quality request with detailed prior-art comparisons (Plex, Beets, iTunes).

Scope & Boundaries

In scope

  • Per-user statistics dashboard (accessible from user profile/settings area)
  • Metrics: total listen time, most played artists, most played genres, most played tracks, most active providers
  • A "year in Music Assistant" summary view (end-of-year or on-demand)
  • Recommendation section: "based on your listening, you might like…"

Not in scope

  • Public/shareable stats (privacy-first; keep it personal for now)
  • Aggregate/admin-level stats across all users (separate analytics opportunity)
  • Real-time listening activity feeds
  • Cross-user comparisons

Foreseen solution

  1. Implement a listen-event logging layer on the MA server (track: what was played, when, by whom, from which provider, how long)
  2. Build a statistics computation layer that aggregates listen events into user-facing metrics
  3. UI: a personal stats page accessible from the user avatar/settings, showing: top artists, top genres, listen time breakdown by provider, top tracks
  4. Recommendation row powered by listen history (can start with simple "most similar to your most-played" logic before adding ML)
  5. "Year in Music" view: triggered in December or available on-demand, generates a shareable (but opt-in) summary card

Risks & open questions

  • Privacy: what data is collected, where is it stored, and is it opt-in or opt-out? Needs explicit policy decision aligned with OHF values.
  • Metrics infrastructure is a prerequisite — are we tracking any listen events today? (Marvin confirmed we currently have zero metrics for MA.)
  • Recommendation logic: start simple (collaborative or content-based filtering?) — needs a scoping decision.
  • "Year in Music" shareable card: cross-provider attribution (some providers may not permit derivative public content).

Appetite

Medium–Large. The listen-event logging infrastructure is the foundation and affects the whole system. The UI is relatively straightforward once data exists. May warrant splitting into two opportunities: (1) metrics infrastructure + basic dashboard, (2) year-in-review + recommendations.

Execution issues

No response

Decision log

Date Decision Outcome
2026-06-05 Cross-provider aggregation is a key differentiator ("your year across all providers") Agreed

Metadata

Metadata

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

Status
Draft

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions