getShowVideoUrl was returning a raw proxy URL without calling
buildLiveStreamUrl, so the web-player output profile preference stored in
localStorage was ignored when starting a live stream from the TV Guide,
Program Detail modal, DVR page, Recording Details modal, and Recording Card.
Fixes#1304
getShowVideoUrl was building raw proxy URLs without calling buildLiveStreamUrl,
so the web-player output profile preference stored in localStorage was silently
ignored when starting a live stream from the TV Guide, Program Detail modal,
DVR page, Recording Details modal, and Recording Card.
Fix: import buildLiveStreamUrl in RecordingCardUtils and call it at the end of
getShowVideoUrl so every caller inherits the correct output_format=mpegts
param and any configured output_profile automatically.
Fixes#1304
- Switch engine to postgresql_psycopg3 (PR had wrong engine name,
and we're migrating from psycopg2 to psycopg3 as part of this work)
- Set CONN_MAX_AGE=0 (required by geventpool; PR had None)
- Reduce MAX_CONNS 20→8, REUSE_CONNS 10→3 to avoid exhausting
pg max_connections across 4 uWSGI workers + Celery
- Add pool=False to explicitly disable Django's native psycopg3 pool
Channel.get_stream_profile() read self.stream_profile directly, bypassing
the override system. The override-aware property effective_stream_profile_obj
already existed and called _resolve_effective_fk('stream_profile') which
correctly picks override.stream_profile when set, but nothing in the
streaming path called it.
As a result, a per-channel 'Stream Profile' override saved through the UI
was visible in the channel edit form (yellow pencil indicator appeared) but
silently ignored at stream time — Dispatcharr always used the global default
profile regardless of what was configured per-channel.
Fix: call effective_stream_profile_obj in get_stream_profile() so that all
callers (live proxy url_utils, input manager, views) automatically pick up
channel-level overrides without any further changes.
Fixes#1268
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The provider-info endpoints for both series and movies always returned
data from the highest-priority relation, ignoring the provider the user
had selected in the dropdown. Switching sources in the UI produced no
change in the episode list or movie details.
Root cause: the endpoints had no support for a relation_id query param,
and the frontend never passed one when the user changed the selection.
Fix (backend):
- series provider-info: accept ?relation_id=<id> and query that specific
M3USeriesRelation; fall back to highest-priority when omitted
- movie provider-info: same treatment for M3UMovieRelation
Fix (frontend):
- api.getSeriesInfo / api.getMovieProviderInfo accept an optional
relationId argument and append it to the query string
- useVODStore.fetchSeriesInfo / fetchMovieDetailsFromProvider forward
the argument to the API layer
- SeriesModal.onChangeSelectedProvider re-fetches series info (episodes
included) with the newly selected relation's id
- VODModal.onChangeSelectedProvider re-fetches movie details with the
newly selected relation's id
Fixes#1250
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
