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:09:07 +0200 |
| commit | 59289b82dc8af08c605fd247c90a5c5ec92c6db3 (patch) | |
| tree | 590e2daf81b2feef674f1bd580b9bf40f83addad /packages/meshbay-node/src/meshbay_node/transport | |
| parent | 8b315b99b941f5e08ab9d622c26fb85d4bc64955 (diff) | |
| download | meshbay-59289b82dc8af08c605fd247c90a5c5ec92c6db3.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/transport')
| -rw-r--r-- | packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py | 18 |
1 files changed, 18 insertions, 0 deletions
diff --git a/packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py b/packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py index 2b3e3ee..252e202 100644 --- a/packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py +++ b/packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py @@ -3117,6 +3117,24 @@ class WebRTCPeerSession: if entry is None or media_cache is None: self._send({"type": "error", "detail": "File or media cache not available"}) return + # This only ever recorded the file->tmdb_id mapping, never the + # metadata tmdb_id names — _do_media_meta_request's cache check + # (entry, cache) both agree on media_type, so it trusted the + # mapping — but found nothing under this *new* id in tmdb_meta + # (nothing had ever fetched it), and silently fell through to a + # fresh search using the file's own title, exactly the one that + # produced the wrong match in the first place. Confirmed live: an + # override "stuck" for shows only because their own title happened + # to be enough for that fallback search to land on the right + # answer anyway, coincidentally — never because the override itself + # was actually being honored — and was invisible until a movie + # whose own title search kept landing on the same wrong result + # exposed it. Fetching and storing the real metadata up front is + # what makes the *override* the thing a later lookup finds. + tmdb_client = self._ctx.get("tmdb_client") + if tmdb_client is not None: + meta = await self._tmdb_build_meta(tmdb_client, tmdb_id, media_type, {}) + await media_cache.set_tmdb_meta(tmdb_id, media_type, meta) target_title = entry.display_title or entry.name matched = [e for e in ctx["index"].entries if e.type == "video" and (e.display_title or e.name) == target_title] |