The error you posted is from the DVR trying to get the stream from your IPTV provider so the Channels Client apps can watch it. If the DVR can't get the stream, no Channels client will be able to watch it since they all get it from the DVR, not directly from your IPTV provider.
Do all, or some, or just one channel from that IPTV provider fail for you?
Do they offer any HLS streams that work?
You were sharing a .ts link, but those errors say HLS, are you sure you have MPEG-TS selected?
The DVR says [HLS] in the log whether a stream is MPEG-TS or HLS.
Yes, I triple checked because I figured it was just as likely I made the mistake...but this time I did it right lol. I'll remove and re-add the source later and see if it changes anything. I appreciate everyone trying to help.
In all honesty, you might have better results with a more legitimate source, no offense.
I find the HDMI encoder route tends to work pretty well with a couple Android boxes. I have not run into any reliability issues that way.
Is it possible the source is having an issue?
Is there anything in the log after the digits 461 ?
Maybe an error message explaining why a 461 error.
Unsupported Transport (RTSP) : In some cases, 461 has been used to indicate an "Unsupported Transport" within the Real-Time Streaming Protocol (RTSP)
According to what I was able to look up, this is what 461 could refer to.
461 isn't defined, depends on the server reporting it.
I don't think so, it works on VLC, Emby, Tivimate, etc. Seems like something changed with Channels but perhaps not. I don't see a smoking gun, though.
I'm sorry you're not answering some of the questions people are asking, what comes after the error 461? Is it defined in someplace, that might be helpful information.
Nothing after. And my research was the same that 461 isn't a standard defined error.
Also, what do you mean when you say the HDMI encoder route?
Like a LinkPi unit, ADBTuner or ah4c and a legit TV provider like DirecTV, YouTube TV, Hulu Live, Sling. It's way more reliable and running in your house on your own hardware. PrismCast is now popular and works well too.
Ah, got it. Iptv provider has been solid, but it's an iptv provider so things change.
Yeah, I mean those companies are all like a teeny bit shady so who knows. Someone else just posted today that their IPTV stopped working. So like who knows what these guys are doing. For sheer reliability, it's definitely worth looking into one of the other community support adoptions.
I'm having the same issue. No problems in VLC or other apps. Channels will not load.
failed to load m3u: failed to retrieve m3u: GET: 461 error. Nothing in logs.
My TVE channels all work fine. Seemed to happen between last night and this morning sometime.
I do use an m3u editor to cut down and organize the channels. Looking at the code details in VLC I don't see anything that jumps out at me as unusual. Weird that so many other apps can stream without issue but Channels cannot. 
Same issue for me, getting 461 trying to start stream. Am able to curl the same url without issue in a shell in channels DVR docker container too
What command can I run to debug this more?
Possibly related to the user agent Channels DVR is presenting?
I remember there was recently a change to that.
Ooh...so is there a way to force the user-agent to something specific? I'm not sure the provider is going to change the user-agents they accept.
My 2 cents, this is ALL from AI (CoPilot, HaHa, so it could be all BS !!
i could be way off base: I have had connection dropped issues with .ts sometimes.
timing absolutely matters for .ts segments, and this can cause drops even when the same stream works fine in VLC or TiviMate.
But the important nuance is this:
The player doesn’t “expect TS chunks faster” — it expects them on schedule , matching the HLS playlist timing.
If the server or network can’t deliver them at the expected pace, the stream stutters or drops.
.ts segments are:
If a segment arrives late, the player can’t decode the next frame → stream drops.
VLC and TiviMate have:
Some IPTV apps (especially lightweight ones) have:
So they drop when .ts is even slightly late.
Also for 461
Some providers allow only:
If you exceed it → 461.
461 is not a standard HTTP code. IPTV panels (Xtream Codes, XUI, etc.) use it as a custom error.
It typically means:
Some servers generate temporary URLs. If the .ts link expires, the server returns 461.
Some IPTV servers block:
If the server thinks you're requesting segments too fast or too slow, it drops you.
Why the error says “Could not start stream for [M3U_Filename] ch2109”
Your player is trying to load the first .ts segment for that channel. The server rejects it → the app reports the channel cannot start.