[Bug]: No user-agent being sent in stream probes or previews from ECM

[hudsgiant]

ECM Version

0.18.2-0027

Priority

Priority 4: When you get to it

What is the bug?

Issue appears to be a lack of user-agent header being passed by ECM. Gemini suggests:

Root Cause Analysis

1. What Dispatcharr Does
   When you preview or play a channel in Dispatcharr:

• Playback routes through Dispatcharr's proxy (/proxy/ts/stream/<channel_uuid>).
• In apps/proxy/live_proxy/input/manager.py and http_streamer.py, Dispatcharr fetches the stream with an explicit User-Agent header:
• It checks the stream's M3U Account or StreamProfile (on your setup, these are configured to use TiviMate: TiviMate/5.1.6 (Android 12)).
• If none is set, it falls back to Dispatcharr's default (VLC/3.0.20 LibVLC/3.0.20).
  IPTV providers recognize the legitimate media client header and serve the stream (typically returning a 302 Found redirect followed by 200 OK).

2. What EnhancedChannelManager Does
   When you preview a stream in EnhancedChannelManager (Streams pane):

The frontend requests GET /api/stream-preview/{stream_id} from stream_preview.py.
ECM obtains the raw provider URL from Dispatcharr and attempts to connect directly to the IPTV provider using stream_request() or validated_subprocess_input().

No headers or User-Agent parameter is passed in stream_preview.py:
python
# backend/routers/stream_preview.py (lines 106-113)
async def passthrough_generator():
    async with stream_request(
        stream_url, timeout=None, initial_target=initial_target
    ) as response:
        response.raise_for_status()
        async for chunk in response.aiter_bytes(chunk_size=65536):
            yield chunk

Because no headers are specified, the underlying Python httpx client sends:
http User-Agent: python-httpx/0.27.x

Most commercial IPTV providers immediately drop connections or return HTTP 403 / 406 / Connection reset when they detect python-httpx.
mpegts.js in the browser receives the HTTP error and aborts playback.

(Note: Interestingly, in ECM's stream_prober.py, the author noticed this issue for bitrate probing and added headers = {"User-Agent": "VLC/3.0.20 LibVLC/3.0.20"}, but omitted it in stream_preview.py.)

Steps to Reproduce

Seems to affect some providers and not others, but basically either just preview a stream for an affected provider in ECM. It will fail, but work fine from within Dispatcharr - both on the same network.

Screenshots / Logs / Artifacts

No response

Additional Context

No response

[hudsgiant]

Secondary issue:

Related blocker: HTTPS-to-HTTP redirect refusal (SSRF security policy).

What Happened in the Log
User-Agent Worked: The log shows resolve_stream_user_agent ran, found M3U account 31, and sent the TiviMate User-Agent. The provider accepted it and returned 302 Found:

log
HTTP Request: GET https://operator1.fikar.xyz/live/... "HTTP/1.1 302 Found"
The 403 Forbidden Block:

The provider's initial entrypoint URL was https://...
Its 302 Found redirected to an unencrypted stream node on http://...
ECM has an SSRF protection layer (backend/security/ssrf.py) that blocks scheme downgrades by default:

if from_scheme == "https" and to_scheme == "http":
    if scheme_downgrade is not SchemeDowngrade.ALLOW_STREAM_PROBE:
        raise SSRFError("Refusing redirect that downgrades https → http")

When SSRFError is raised, stream_preview.py converts it to HTTP 403 Forbidden:

except SSRFError:
    raise HTTPException(status_code=403, detail="Stream destination is not permitted")

ECM's background stream prober was already configured to allow this (SchemeDowngrade.ALLOW_STREAM_PROBE) because IPTV providers frequently use HTTPS for portal redirection and HTTP for edge streaming, but stream_preview.py had not enabled the flag.

[hudsgiant]

also hit this while diagnosing the above two issues:

What Just Happened

The 403 Forbidden was not coming from your IPTV provider —it was generated internally by ECM's SSRF (Server-Side Request Forgery) validator:

How ECM Validates Streams:
Before launching FFmpeg to preview or transcode a stream, ECM validates the URL and every HTTP redirect against an internal IP blocklist (preventing connections to internal LAN/cloud metadata IPs).

The Root Cause:
To validate the IP, ECM performs a DNS lookup via socket.getaddrinfo(hostname). Because IPTVChannelManager routes its network traffic through your gluetun VPN container, transient UDP packet drops or brief DNS latency on the VPN tunnel can cause an occasional socket.gaierror ("Temporary failure in name resolution").

Instant Fail-Closed: In backend/security/ssrf.py, any DNS resolution error is treated as a security rejection (SSRFError: Could not resolve host 'xxx.xxx.xxx' — rejected (fail-closed)). backend/routers/stream_preview.py then intercepts that SSRFError and immediately throws:

python
raise HTTPException(status_code=403, detail="Stream destination is not permitted")

Because there were zero retries on DNS resolution and no warning logged in ecm.log, a 100ms DNS hiccup over the VPN resulted in an immediate 403 Forbidden.

Verification: When tested directly inside the container right after, xxx.xxx.xxx resolved cleanly to xxx.xxx.xxx.xxx, followed the HTTP 302 redirect to http://xxx.xxx.xxx.xxx:3000/..., and streamed without issue.

Recommended Fix
Transient DNS Retry in backend/security/ssrf.py: Add up to 2 fast retries (with a 100ms backoff) on socket.gaierror / OSError inside _resolve(). This prevents momentary VPN DNS packet loss from failing the stream while preserving the strict fail-closed security boundary.

Diagnostic Logging & Clearer Status in backend/routers/stream_preview.py:
Log the exact exception message when SSRF validation fails so ecm.log explicitly records the reason, and return 502 Bad Gateway if DNS cannot resolve rather than a misleading 403 Forbidden.

[MotWakorb]

Merged in #1001 and now published in the dev image as 0.18.2-0032:

ghcr.io/motwakorb/enhancedchannelmanager:dev

This includes consistent configured User-Agent headers for direct stream previews and probes, provider-preview HTTPS-to-HTTP redirect support with destination validation retained, bounded retries for transient DNS failures, clearer startup errors, and safer playback diagnostics.

A new Stream User-Agent selector is available under Settings → Appearance → Stream Preview, with Use Dispatcharr User-Agent (Default) plus Chrome, Firefox, Safari, VLC, and TiviMate presets. The default resolves the M3U account User-Agent and then Dispatcharr's global default; channel previews continue through Dispatcharr's proxy.

To verify:

1. Update to the dev image and confirm ECM shows 0.18.2-0032.
2. Leave Use Dispatcharr User-Agent (Default) selected, click Save Settings, and retry an affected direct stream preview and probe.
3. If you need to force the provider's TiviMate identity, select TiviMate, save, and retry.

Please confirm whether the affected provider now works. If it still fails, include the preview mode and relevant [PREVIEW] or [STREAM-PROBE] diagnostic, with credentials omitted. Leaving this issue open pending confirmation.

[hudsgiant]

Heres what my AI overlord tells me regarding the fixes: