yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

Store poster_path, backdrop_path and rating on movies and series #145

New Issue
Closed
opened 2026-08-23 19:40:54 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-23 19:40:54 +01:00
Owner
Copy Link
Copy Source

Depends on: #142

§9.6 keeps rich detail out of the database and serves it through arr-meta's 24h
cache. Three fields are the deliberate exception, because the views that need
them are pure SQL: the in-library half of unified search (§9.2) and the library
view read movies and series directly, and a poster on those rows would
otherwise cost one TMDB call per row on every search.

Add to both movies and series:

poster_path    TEXT
backdrop_path  TEXT
vote_average   REAL

Nullable, no default. A title added before its first metadata refresh has no
artwork yet and the UI has to handle that anyway — TMDB has entries with no
poster at all.

  • Migration follows the numbering and the STRICT convention already in
    crates/arr-db/migrations/. REAL is a valid STRICT column type; a rating
    is not an integer and storing it scaled would be a trap for whoever reads it
    next.
  • The daily metadata refresh in arr-daemon writes all three, alongside the
    fields it already refreshes. This is the whole point of the issue: a column
    nothing fills is worse than no column.
  • The add flows (POST /api/movies, POST /api/series, and the unified-search
    add path) fill them from the TMDB response they already hold, so a title
    added today has a poster before tomorrow's refresh.
  • vote_count is deliberately not stored. It is context for a rating on a
    detail page, which is served live, not something the library grid shows.

Regenerate the sqlx query data — several queries are SELECT-listed by hand.

Non-goal: no backfill job for titles already in the library. The daily refresh
reaches every one of them within a day and a one-off job would be dead code by
the end of the week.

Depends on: #142 §9.6 keeps rich detail out of the database and serves it through arr-meta's 24h cache. Three fields are the deliberate exception, because the views that need them are pure SQL: the in-library half of unified search (§9.2) and the library view read `movies` and `series` directly, and a poster on those rows would otherwise cost one TMDB call per row on every search. Add to both `movies` and `series`: ``` poster_path TEXT backdrop_path TEXT vote_average REAL ``` Nullable, no default. A title added before its first metadata refresh has no artwork yet and the UI has to handle that anyway — TMDB has entries with no poster at all. - Migration follows the numbering and the `STRICT` convention already in `crates/arr-db/migrations/`. `REAL` is a valid STRICT column type; a rating is not an integer and storing it scaled would be a trap for whoever reads it next. - The **daily metadata refresh in `arr-daemon` writes all three**, alongside the fields it already refreshes. This is the whole point of the issue: a column nothing fills is worse than no column. - The add flows (`POST /api/movies`, `POST /api/series`, and the unified-search add path) fill them from the TMDB response they already hold, so a title added today has a poster before tomorrow's refresh. - `vote_count` is deliberately not stored. It is context for a rating on a detail page, which is served live, not something the library grid shows. Regenerate the sqlx query data — several queries are `SELECT`-listed by hand. Non-goal: no backfill job for titles already in the library. The daily refresh reaches every one of them within a day and a one-off job would be dead code by the end of the week.
naps62-yolo added this to the Rich metadata milestone 2026-08-23 19:40:54 +01:00
naps62-yolo added the difficulty/easyarea/dbphase/6-tvtype/feature labels 2026-08-23 19:40:54 +01:00
naps62-yolo added a new dependency 2026-08-23 19:42:42 +01:00
#142 Amend DESIGN.md for the title detail surface
naps62-yolo added a new dependency 2026-08-23 19:42:42 +01:00
#147 Posters and ratings on both sides of search results
naps62-yolo added a new dependency 2026-08-23 19:42:42 +01:00
#151 Library poster grid with a list toggle
naps62-yolo added phase/5-ui and removed phase/6-tv labels 2026-08-23 19:42:55 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/db difficulty/easy phase/5-ui type/feature
Milestone
No items
No Milestone Rich metadata
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Blocks
#147 Posters and ratings on both sides of search results
yolo/arr
#151 Library poster grid with a list toggle
yolo/arr
Depends on
#142 Amend DESIGN.md for the title detail surface
yolo/arr
Reference: yolo/arr#145
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?