Distro is not working inside CDVR. They are getting the error "Streaming to the tuner failed" 404.
Thank you.
Unfortunately, I don't have an old version to upgrade FROM to test this, but pushing v2.9.1 to attempt to fix that migration issue. Please give it a shot (may need to refresh your M3U in CDVR after upgrade).
1 Like
Just as a basis for comparison, I’m using FastChannels and I have Distro set up and I’m currently watching good ol’ Kaloopy, without any issue.
Thanks, I'm glad that Distro is working. I updated to Fastchannels 2.9.0 yesterday. It appears that I need to refresh the m3u and guide data. I don't recall doing that for 2.8.
After doing both m3u and EPG reloads, I can view the channels but the guide is not updating. I'll try deleting and rebuilding guide data if that's what it takes. I'll check my DVR schedule before I do that.
@KineticMan - FYI
Update: After the EPG finished refreshing, the 404 errors returned. Simply refreshing the m3u a second time fixed it. There is still no guide data in the grid or the home cell but the program information is there when I tune in the channel. The recurring 404 errors are also puzzling.
I will try rebuilding the EPG early this afternoon. I hope that's not necessary but I may also try to rebuild the sources as well. (And then there're the collections.)
@KineticMan quick side question. Do you have an official (or unofficial) icon at a URL somewhere for this project? In the UnRaid Docker manager, you can add an icon for a project and I would like to make it look more pretty. 
Below is an example:
For example, for E+TV, it gets the icon from the following URL:
https://i.imgur.com/LrdVje2.png
yea i'm puzzled too..
if you could help me debug, that'd help. If you could download the M3U in Notepad, find a Distro channel and copy/paste here. Then, in your FastChannels logs, when you tune a channel from CDVR, it should log the tuning attempt - paste that here too.
m3u will look like this ->
#EXTM3U #EXTINF:-1 channel-id="distro.US:39730" tvg-id="distro.US:39730" tvg-name="24 Hour Free Movies" group-title="Movies" tvg-logo="http://192.168.86.72:5523/logos/9953a821f2b79534c7b512fcfe5fd231.png" tvg-chno="600000",24 Hour Free Movies http://192.168.86.72:5523/play/distro/US%3A39730.m3u8
and logs like this:
2026-04-07 10:52:58,802 INFO app.routes.play: [play] request ip=192.168.86.72 source=distro channel_id=US:39730 channel_name=24 Hour Free Movies
2026-04-07 10:52:59,165 INFO gunicorn.access: 192.168.86.72 "GET /play/distro/US%3A39730.m3u8 HTTP/1.1" 302 481 0s
2026-04-07 10:52:59,449 INFO app.routes.play: [play] request ip=192.168.86.72 source=distro channel_id=US:39730 channel_name=24 Hour Free Movies
2026-04-07 10:52:59,719 INFO gunicorn.access: 192.168.86.72 "GET /play/distro/US%3A39730.m3u8 HTTP/1.1" 302 481 0s
found it... Distro made a change with more than half their streams now requiring headers to get the stream to authorize and play. I'm going to implement a lightweight proxy to fix this. Stand by...
2 Likes
Yes my observation also..the indian ones 2 cloudfronts effected. Iptvnator will play them as i think it sends headers for everything.
streamlink also doesnt need the headers.
Fixed...
V2.9.2 pushed
Distro's streams were breaking because the URLs we stored during scraping would expire within a few hours. When you tried to play a channel, the URL was already stale.
On top of that, about 75% of Distro channels sit behind a CDN that blocks requests unless they come from the Distro website — so IPTV apps like Channels DVR were getting rejected.
Fix 1: Instead of storing the actual stream URL, we now store just the channel ID and fetch a fresh URL from Distro's API every time you hit play (cached for 30 min so it's fast).
Fix 2: For the CDN-restricted channels, FastChannels now acts as a middleman — it fetches the playlist file from Distro's CDN using the right headers, rewrites the video segment URLs to point to an open CDN, and hands that back to your player. Your player then pulls the actual video directly from that open CDN with zero bandwidth going through FastChannels.
1 Like
Can you look at mine? not via your tool but i did modify your scraper, but they all still working in iptvnator they havn't expired.
@KineticMan Pulled the update...the good news for me is that the Distro channels I checked will actually play now in the in-app player... no more CORS error... and no need to open externally...
So, now a favor... since that was the CORS/CDN issue with Distro and your update fixed it... is there anyway you could apply this fix to the Samsung TV Plus source?
This is the same error I get with the Clarity 4K, Loupe 4k and Love Nature 4K... haven't tried any other yet...
Update: I just checked a few more Samsung channels, and they are not playing in the in-app player...
Browser preview unavailable for this source (CORS restriction on stream CDN). Use "Open Externally" to play outside the browser preview.
If it's not feasible, then no worries... I'm happy with the update....
What i notice on the 404s
head request 404s but get request gives status 200
I am making a good faith attempt to improve in-browser player experience. I can't make any promises as some of the upstream streams are HEVC and thus just becomes a codec issue that your browser simply might not support. I'll push that out next version.
3 Likes
I completed scanning Distro and other sources. The Distro channels appear in new Collections but they still show up as "no longer exists" in the original Collection. I don't see a way to refresh Collections similar to the way we reload M3Us. Is there a way that I'm overlooking?
collections inside CDVR? it should be instant.. what's your settings for that Channel Collection look like?
I don't see anything to set. What settings are there for collections?
I tried cloning the collection and the channels were missing there, too. The channels DO show up on a brand new collection.
One of the missing channels in the original collection is distro.83817. Could that number have changed when I reloaded the feed from Fastchannels and then reloaded the m3u on the CDVR source?
I'm okay with editing new collections if that's what's necessary. I just wanted to avoid it because I did a few edits on the existing collections.
1 Like
Yes.
It probably changed to distro.US:83817
And when the channel-id for a source channel changes, Channels DVR will also assign it a new channel number if your source is set to ignore channel numbers to allow Channels DVR to assign them.
See this topic (read to the bottom) for a better understanding of how Channels DVR Channel Collections work. Channel duplicates in Collections - Very annoying - Bug? - #18 by chDVRuser
By fishing around, I think I see what's happening. The previously missing channels have reappeared with new index or ID labels, numbers or whatever the nomenclature is under the hood so to speak. I simply need to remove the channels that call themselves missing. Is close to being correct?
Yes.
Wish there was an easy way to mass delete those.
I find it easier to delete the collection and rebuild it.
1 Like