mirror of
https://github.com/Dispatcharr/Dispatcharr.git
synced 2026-07-18 09:06:06 +00:00
Issue: When `process_movie_batch` / `process_series_batch` (apps/vod/tasks.py) creates duplicate vod_movie / vod_episode records during a refresh, existing M3U*Relation rows get repointed to the new records. The old UUIDs that external players (Emby / Jellyfin / ChannelsDVR) cached in `.strm` URLs are left orphaned, and the proxy 404s on every subsequent request — even though the same request already carries a stable `stream_id` that uniquely identifies a live relation. This patch makes `_get_content_and_relation` use a soft UUID lookup and, if it misses, fall back to resolving content via `M3UMovieRelation.stream_id` / `M3UEpisodeRelation.stream_id`. The fallback respects the strictest match first: when `preferred_m3u_account_id` is also present, that account is queried first; otherwise the highest-priority active relation matching the stream_id wins (same ordering the existing relation-selection logic uses). This is read-side graceful degradation, complementary to the write-side root fix proposed in closed #973 (re-use the relation's existing movie/series during refresh rather than rematching by TMDB ID). The two PRs together would fully resolve #961: #973 prevents new orphaning, this PR makes any URL that ships a stream_id survive past orphaning. URLs without a stream_id (e.g. XC-compat `/movie/<user>/<pass>/<id>.mkv`) are NOT covered by this patch — they need the root fix. Series-UUID lookups (`/proxy/vod/series/<UUID>`) are left UUID-only by design — players cache episode and movie URLs, not series URLs. Same pattern can be added as a follow-up if needed. Tests: 7 new mock-based regression tests covering both branches, verified against `:dev`. UUID-first happy path is unchanged (M3U*Relation table never queried when the UUID resolves). Related: #961 (open), closed #973 (root fix abandoned for inactivity). |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| test_profile_connections.py | ||
| test_streamid_fallback.py | ||