diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-26 17:09:07 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-26 17:12:13 +0200 |
| commit | 3d03692b6cc5e47c4bb49b86707a50cdaa5408f2 (patch) | |
| tree | 458b8901cbd590f12463c8623b54ae91b5c42b88 /packages/meshbay-node/src/meshbay_node/ops.py | |
| parent | db7f81fd08742847f3ebea061c75530b7b31b934 (diff) | |
| download | meshbay-3d03692b6cc5e47c4bb49b86707a50cdaa5408f2.tar.gz | |
fix(video): a TMDB override never stored the metadata its chosen id names
Found live: "fix match" appeared to work for two shows but not for a movie
whose own automatic search kept landing on the same wrong result. The
override only ever recorded the file->tmdb_id mapping — never the
metadata that id actually names. _do_media_meta_request's cache check
agrees the mapping is fresh (same media_type) but finds nothing under
that *new* id in tmdb_meta, since nothing had ever fetched it, and falls
through to a brand-new search using the file's own title — reproducing
the exact match the override was meant to replace.
This stayed invisible for the two shows only because their own title
happened to be enough for that fallback search to land on the right
answer anyway, entirely independent of whatever the override recorded —
never because the override was actually being honored. It surfaced on a
movie whose own title search kept landing on the same wrong match
regardless.
Fetches and stores the real metadata for the chosen tmdb_id up front (via
the existing _tmdb_build_meta, which needs only the id — no search result
object required), so a later lookup finds the override itself instead of
falling through to a search blind to it.
Diffstat (limited to 'packages/meshbay-node/src/meshbay_node/ops.py')
0 files changed, 0 insertions, 0 deletions