aboutsummaryrefslogtreecommitdiffstats
path: root/poc
diff options
context:
space:
mode:
authorChristophe Besson <cbesson@gmail.com>2026-08-26 17:09:07 +0200
committerChristophe Besson <cbesson@gmail.com>2026-08-26 17:12:13 +0200
commit3d03692b6cc5e47c4bb49b86707a50cdaa5408f2 (patch)
tree458b8901cbd590f12463c8623b54ae91b5c42b88 /poc
parentdb7f81fd08742847f3ebea061c75530b7b31b934 (diff)
downloadmeshbay-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 'poc')
0 files changed, 0 insertions, 0 deletions