Mpeg-ts Streams broken - Not following 302 Redirects

Channels DVR Server Troubleshooting
#1

2026.04.29.0232 Pre-Release - Tested on current stable too, but both seem to not be working.

My IPTV provider recently migrated domains and shifted to CDN-based stream delivery, which broke some things. After ruling out firewall, credentials, network routing, and provider-side issues, I captured traffic on the DVR machine and might have found the actual problem: Channels DVR receives a 302 redirect and never seems to follow it?

Dug into it and captured traffic on the DVR box while triggering a stream. The pcap shows Channels DVR connects to the origin, gets a 302, and just stops. Never connects to the redirect target. Zero traffic to the CDN IP that I can tell.

The redirect chain:

  1. GET https://[origin]:443/live/.../channel.ts
  2. 302 redirect to http://[cdn]:80/live/play/[token]/channel&secret_token=...
  3. CDN returns 200 + video/mp2t

Channels DVR handles step 1 and seemingly stops. Everything else (vlc, etc) follows it through and streams fine.

tshark -r cdvr.pcap -T fields -e ip.dst -e tcp.dstport | sort -u

[origin-ip]    443

Looks like Channels just doesn't follow 302s on .ts stream requests? At least when the redirect downgrades from HTTPS to HTTP on a different domain. Below is a CURL from the same machine...

curl -L -v "https://[origin]/live/[credentials]/[channel].ts"

< HTTP/2 302
< location: http://[cdn]:80/live/play/[token]/[channel]&secret_token=[token]

* Issue another request to this URL: 'http://[cdn]:80/live/play/[token]/[channel]&secret_token=[token]'
* Connected to [cdn] port 80
< HTTP/1.1 200 OK
< Content-Type: video/mp2t
100 10.9M    0 10.9M    0     0   875k      0 --:--:--  0:00:12
#2

The problem with the plpaylist is best solved with a third party application like m3u-editor.

Load the playlist and use any access details provided and view and setup your list and even view the video inside th editor.
The links can then be directed to channels.
IPTV isn't officially supported here.

Good luck.

#3

I did put a small Python script on my Channels DVR server to work around this. It acts as a local proxy. It serves a rewritten version of my M3U playlist where all the stream URLs point at localhost instead of the provider.

When Channels DVR requests a stream, the proxy script fetches it from the real provider, follows the 302 redirect automatically, and pipes the stream back. Channels DVR never sees the redirect, just a direct stream from localhost. So it seems the redirect is the issue... once the proxy is in play, everything works excellently...

#4

What user agent does your proxy receive from the DVR? What user agent header is it sending out?