I think i found the issue…maybe….
In my main post i commented how i thought it was weird it was handling the streams as HLS.
So could it be taking our MPEG-TS streams and converting them to HLS which then throws the error?
This is the exact timeframe when things broke and the error does seem to make sense of it saying cant play format if its looking for ts and is getting hls….
The error is an HTTP error code coming from the server. This isn’t an issue with the DVR. The server is returning an error when the DVR makes an HTTP request.
Is there any clear reason why it works in every other player but Channels?
Exact same issue, it just stopped working for me the other day.
Same config, same sources. Multiple different sources, so it isn't that just one blocked or stopped working.
You’re having a GET error with HTTP status 461?
I don’t know why your custom channel source would return an error. You would have to follow up with them.
Looks like it might be blocking the channels user agent because it could appear like a restreamer or proxy.
Is there any way we could modify the usersgent it utilizes in its request…maybe to VLC
VLC/3.0.20 LibVLC/3.0.20
We're now using a non-default User-Agent.
That solved it! Thank you!!!!!!
I have been having this exact problem for 3 or 4 days now. Same error using Custom Channels with two different M3U sources. It literally popped up out of the blue. It was working, and then a few hours later I get the "Couldn't get the master playlist... *.ts: 461. Absolutely nothing will record.
I'm not using Tailscale, and I try and route all of my traffic through a VPN. I've tried different VPN endpoints, and even bypassing the VPN. Nada.
Welcome to the Channels Community Forum!
If you feel it's the same problem, did you try the solution described in the post a couple above yours?
Https://myprovider.com:80/etcetc
Remove the :80.
If you filter your url/playlist elsewhere before channels make sure your original input url has that port removed or all your stream urls will still have the port.
I'm assuming you mean for me to download the latest pre-release, correct? That could be a problem.
I use Tim Stephens docker container in Unraid, and unless he has the prelease in his repository, it's going to be hard to do.
Just for the sake of argument, where are the pre-Releases stored?
I'm sorry. I don't have a clue what you just said here. I understand the pre-release version. Everything after that is a bit to vague for me to understand
Do you use a m3u url as your source? If there is a port in the url it may not process it properly
For instance, if you use m3u and anywhere in your process the m3u has a port 80 like this:
https://myprovider.com:80/mytv.php?type=m3u_plus&output=ts
Remove the port number from the url.
https://myprovider.com/mytv.php?type=m3u_plus&output=ts
That change and using the prerelease should solve the issue.
Ah, I understand now. No, that was not the problem. I was able to upgrade the container using the Server Information pull down. After that, it began to work.
Thank you for your massive assistance!
Channels should support custom tags in m3u files used to fetch streams like User-Agent or Referer. I have to fiddle with nginx config used as a forward proxy to overcome this.
Did this get reverted recently @eric? I'm getting 461 again and after some debugging in my docker container shell, I tested a bunch of different user agents, including dummy ones, null ones, and VLC ones, all of them worked fine. However, when I specifically tried the user agent: Go-http-client/1.1 is when I received 461. I suppose it's possible whatever non default user agent channels uses got blacklisted but it feels less likely the case 
Edit: adding custom user agent to m3u works, meaning channels added support for custom user agents. see my post here Stream fails in Channels app and Chrome but works in VLC - #35 by addd45
No, nothing has been reverted.
