fix(explore): match Plex Discover titles to the library again

Two defects sank Explore's Plex integration. Discover started rejecting
X-Plex-Container-Size=500 with a 400, so the watchlist membership
snapshot never loaded: hearts stayed unknown and toggles dead. The
snapshot now pages at 100, and getWatchlist refetches a rejected page in
chunks of the row fetch's field-proven 25, so the next cap drift degrades
gracefully instead of failing and callers' offset math survives either
way.

Worse, every Plex catalog item reached the library matcher carrying only
its Discover rating key: listings were fetched without includeGuids, so
the lookup rested entirely on exact plex:// guid equality between two
metadata universes (Discover duplicate entries break it, notoriously for
anime), and the title fallback can never confirm a candidate without
external ids to intersect - "Not in your library" for owned titles the
MAL provider matched fine. Discover listings now request Guids, the
detail screen re-runs the matcher when enrichment gains id forms
(generation-guarded so the slower bare lookup cannot overwrite the
richer verdict), the matcher keys its memo by id fingerprint so the poor
form's cached negative cannot answer for the rich one, and the Plex
client stops burning title requests that external-id verification is
guaranteed to reject.

Discover requests are now logged like every other API surface; this bug
shipped blind because they were not.

close #1715
This commit is contained in:
edde746
2026-07-30 01:33:46 +02:00
parent 53288116fe
commit 1bf7aac75b
9 changed files with 268 additions and 12 deletions
+5
View File
@@ -3876,6 +3876,11 @@ class PlexClient
}
}
// Title attempts confirm candidates by external-id intersection, so
// without external ids they cannot match anything — stop at the exact
// guid lookup instead of burning requests that always come back empty.
if (!ids.hasAny) return null;
Future<({Map<String, dynamic>? modern, Map<String, dynamic>? legacy})> attempt(
String title, {
required int size,