gronod/ombi-mcp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

read_media tvdb details: requested flag false for an approved/requested series #7

New Issue
Closed
opened 2026-09-19 08:20:23 +01:00 by gronod · 1 comment
gronod commented 2026-09-19 08:20:23 +01:00
Owner
Copy Link
Copy Source

Summary

read_media details for tv via provider: tvdb reports requested: false for the media and every season even when the series has an approved request on the instance.

Environment

Reproduction

Seven Up! (tvdb 259032) was requested and approved on 2026-09-19 — visible via read_requests recent and in the retry queue.

read_media {"action":"details","media":"tv","provider":"tvdb","id":259032}

Expected

requested: true on the media (and requested seasons), matching read_requests state.

Actual

requested: false on the media and all 10 seasons. by_request for Button Moon (parent 759) correctly shows requested state — so the discrepancy is specific to the tvdb details route.

Notes

The tvdb path now uses /api/v1/Search/tv/info/{id} (TVMaze-backed). That route may not carry request state for items the local instance has already requested — possibly needs a follow-up availability/request lookup. Alternatively upstream just omits the flag for this series. Needs verification before classifying as projection vs upstream.

Correlation ID

05cc8a8fd09fb596bf5acd1d

## Summary `read_media` `details` for tv via `provider: tvdb` reports `requested: false` for the media and every season even when the series has an approved request on the instance. ## Environment - Binary: deployed darwin-amd64 build from `develop` @ `d047d76` - Ombi: 4.53.10 (https://ombi.i3omb.com), JWT auth ## Reproduction Seven Up! (tvdb `259032`) was requested and approved on 2026-09-19 — visible via `read_requests recent` and in the retry queue. ```json read_media {"action":"details","media":"tv","provider":"tvdb","id":259032} ``` ## Expected `requested: true` on the media (and requested seasons), matching `read_requests` state. ## Actual `requested: false` on the media and all 10 seasons. `by_request` for Button Moon (parent 759) correctly shows requested state — so the discrepancy is specific to the tvdb details route. ## Notes The tvdb path now uses `/api/v1/Search/tv/info/{id}` (TVMaze-backed). That route may not carry request state for items the local instance has already requested — possibly needs a follow-up availability/request lookup. Alternatively upstream just omits the flag for this series. Needs verification before classifying as projection vs upstream. ## Correlation ID `05cc8a8fd09fb596bf5acd1d`
gronod added this to the M5 — Request state and list routes milestone 2026-09-19 08:57:53 +01:00
gronod commented 2026-09-19 15:13:32 +01:00
Author
Owner
Copy Link
Copy Source

Retested on binary 6ebcb2f (M5 applied) — not fixed. The overlay either never runs or never matches on this instance.

Live evidence — all three series have approved parent requests, yet tvdb details still report requested:false with no request_targets and no warnings:

read_media details {media:tv, provider:tvdb, id:75150}   → Button Moon                 requested:false (real parent request id 759 — verified via tmdb details + get)
read_media details {media:tv, provider:tvdb, id:259032}  → Seven Up!                   requested:false (requested & approved today, visible in recent/retry_queue)
read_media details {media:tv, provider:tvdb, id:270814}  → Death Comes to Pemberley     requested:false (real parent request id 908 — verified via get)

No request state scan incomplete warning was emitted on any call, so either:

  1. The overlay is skipped because jint(m, "requestId") != nil — i.e. the v1 TVMaze info response already carries a requestId field (possibly 0/absent-value), defeating the requestId == nil guard in mediaDetails; or
  2. eachTVRequestParent scans GET /api/v1/Request/tv/{count}/{pos}/1/0/0 without error but no parent record matches — plausibly because parent records name the field theTvDbId rather than tvDbId (mergeTVRequestState only checks tvDbId/imdbId, while projectRequest reads both tvDbId and theTvDbId).

Related: the same bounded scan backs the read_requests search tv fallback (see #10 comment) and that path demonstrably fails on this instance — worth verifying the scan endpoint actually returns data here.

Retested on binary `6ebcb2f` (M5 applied) — **not fixed**. The overlay either never runs or never matches on this instance. Live evidence — all three series have approved parent requests, yet tvdb details still report `requested:false` with no `request_targets` and no warnings: ``` read_media details {media:tv, provider:tvdb, id:75150} → Button Moon requested:false (real parent request id 759 — verified via tmdb details + get) read_media details {media:tv, provider:tvdb, id:259032} → Seven Up! requested:false (requested & approved today, visible in recent/retry_queue) read_media details {media:tv, provider:tvdb, id:270814} → Death Comes to Pemberley requested:false (real parent request id 908 — verified via get) ``` No `request state scan incomplete` warning was emitted on any call, so either: 1. The overlay is skipped because `jint(m, "requestId") != nil` — i.e. the v1 TVMaze info response already carries a `requestId` field (possibly 0/absent-value), defeating the `requestId == nil` guard in `mediaDetails`; or 2. `eachTVRequestParent` scans `GET /api/v1/Request/tv/{count}/{pos}/1/0/0` without error but no parent record matches — plausibly because parent records name the field `theTvDbId` rather than `tvDbId` (`mergeTVRequestState` only checks `tvDbId`/`imdbId`, while `projectRequest` reads both `tvDbId` and `theTvDbId`). Related: the same bounded scan backs the `read_requests search tv` fallback (see #10 comment) and that path demonstrably fails on this instance — worth verifying the scan endpoint actually returns data here.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone M5 — Request state and list routes
Projects
Clear projects
No projects
Assignees
Clear assignees
gronod
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Depends on
#6 read_media details: duplicate imdb, missing tmdb, bogus tvmaze identifier
gronod/ombi-mcp
Reference: gronod/ombi-mcp#7