summaryrefslogtreecommitdiffstats
path: root/packages/meshbay-node/src/meshbay_node/transport
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 /packages/meshbay-node/src/meshbay_node/transport
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 'packages/meshbay-node/src/meshbay_node/transport')
-rw-r--r--packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py18
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 724527b..f95e59e 100644
--- a/packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py
+++ b/packages/meshbay-node/src/meshbay_node/transport/webrtc_server.py
@@ -3105,6 +3105,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]