A new approach to making IPTV behave more like traditional tuners

#21

Thank you to everyone who took the time to review and discuss the proxy architecture design I shared here.

As some of you know, I originally built this project to work entirely through the Emby API. As development progressed, I discovered that the available APIs couldn't reliably determine when files were actively being updated. Without that level of visibility, it wasn't possible to guarantee safe file updates or consistently protect against corruption during provider failures.

That realization led me to redesign the architecture from the ground up. Rather than relying solely on application-level APIs, the new engine works directly with the operating system to determine the true state of files before making changes. The result is greater stability, improved performance, and significantly stronger reliability.

I'm also excited to announce that I'm officially partnering with @Fyb3roptik where my proxy code will be integrated directly into his Kernel Media Server, giving us a foundation that goes well beyond the limitations of existing solutions.

Together, we're building a platform that delivers native HLS/DASH streaming, higher availability, and a more resilient architecture designed for long-term reliability and performance.

Thank you again to everyone who shared feedback and ideas throughout this journey. Your input helped shape the direction of this project, and I'm excited to share what's coming next.

5 Likes
#22

I completely understand the frustration—I’ve spent plenty of time wrestling with the same kinds of .ts stream issues.

Channels DVR has been built around a clear set of priorities, and @tmm1 has done an outstanding job creating a reliable, polished experience for the vast majority of users. Every project has its own goals and design decisions.

1 Like
#23

Yes, the whole CDVR team have done an outstanding job,
when I compare the CHDVR app to DirecTV, YoutubeTV,etc Apps, CHDVR runs circles around them,
and lets not forget the entire community, may of whom have also created outstanding add-on projects.
My only request of you is.... Please make it as simple and easy to use as possible. :joy:
Some of us here love all this, but would rather not go down a rather deep rabbit hole.
Thanks again to all.

#24

Agreed, @Flt505! The setup is plug-and-play: just pipe your provider through my solution and point your Channels DVR source to it. Your existing EPG and recording schedules remain completely untouched—I’m simply providing the engine to keep your streams reliable.

While it’s ready to go out of the box, I’ve included optional advanced settings for encoding and scaling to ensure smooth performance on tricky connections, like RV satellite. Bottom line: I’m letting the DVR be the DVR and the client be the client, liberating each to do what it does best. :slightly_smiling_face:

#25

A lot of what this solution offers could have been provided by simply maintaining a sufficient buffer before starting the playback on the client. E.g do not play unless there is 15s of video buffer accumulated. I think it was suggested in the past. Nobody cares in the digital world about sub minute delays.

#26

@hal9000,

That’s true for network jitter, but a client buffer can't fix a broken transport socket. If the upstream feed drops, the connection tears down and the player errors out instantly—wiping out that 15-second buffer anyway.

We’ve seen platforms like Emby try to brute-force this by retrying tuner handshakes (up to 11 times a minute), but it fails because they aren't checking the 'truth' of the stream. Without a data-aware heartbeat constantly asking, 'Is video actually writing?', the system just freezes on dead air while the socket technically stays open.

#28

The stream delivered to Channels DVR is a standard HLS stream (default), or MPEG-TS when required by platforms such as Emby, regardless of whether the original source is .ts or .m3u8.

This approach addresses a common challenge with IPTV playlists: mixed stream formats. When a provider’s playlist contains different types of streams, users are often forced to select a single global format in Channels DVR. In practice, this can result in some channels working correctly while others fail because they do not match the selected format.

The system handles this by normalizing streams before they reach the DVR:

  • Format Handling: The engine accepts different upstream stream types and converts them into a consistent output format.
  • Real-Time Normalization: Instead of sending mixed source URLs directly to the DVR, the proxy processes and standardizes each stream as it passes through.
  • Provider Separation: The DVR does not need to manage the differences between upstream formats. The provider’s feed is handled by the transcoder layer, while the DVR receives a predictable, compatible stream.

The End Result: Channels DVR can simply be configured for HLS, while the complexity of handling different source formats is managed upstream. This reduces configuration issues, avoids format-related troubleshooting, and provides a more consistent playback experience.

#29

Hi,

I'm going to halt this thread as I've personally deemed it not trust worthy.

  1. You have not provided an actual project, but are inviting our community members to reach out to you.
  2. Its source certainly isn't open for anyone to look at.
  3. You're making promises that, us developers, find to be a bit nonsense.
  4. Your posts are vibrating with generative AI vibes.
  5. You aren't even a subscriber of Channels.

I'd be happy to be proven wrong, and if I am, please send me a private message and we can chat.

But out of the interest of protecting this community, I'm closing this thread.

3 Likes
#30