A new approach to making IPTV behave more like traditional tuners

[EODCrafter 181]

21 minutes ago, thejacer87 said:

@PowerCCwhere can I find the install instructions? I couldn't find anything in google or github.

Kernel — Your Media, Your Way https://share.google/mJyjayR4H3qqgYaNk

[thejacer87 9]

45 minutes ago, EODCrafter said:

Kernel — Your Media, Your Way https://share.google/mJyjayR4H3qqgYaNk

Sorry, I clearly don't fully understand everything here. But I need to install KMS and XCStream?...

PowerCC said: "Another media server can integrate with XCstream directly and use it as the continuity engine."

So how do I get this setup with my Emby? KMS downloads have no readme, and despite the site mentioning docker installation, I don't see any docker instructions.

Thanks

[ExploitPanda 0]

I am also curious to test this project out with Emby

[PowerCC 28]

A little more news, because I know several of you have been following this from the beginning.

XCstream has reached the point where I’m comfortable saying that there will be a standalone public beta.

What started as an Emby-focused watchdog has evolved into something much narrower and, I think, much more useful: a dedicated MPEG-TS live-stream continuity engine.

The biggest change along the way has been pass-through. Earlier in development I expected hardware transcoding to be the safest default. Real-world testing changed my mind. XCstream can now remux, buffer, validate, monitor and recover a live stream while preserving the original video and audio whenever possible. A dedicated GPU is no longer required for normal operation. That is a pretty significant shift from where this project started.

I also want to give a big thank-you to Nick (Fyb3roptik) and the Kernel Media Server project. Nick has been incredibly open to testing XCstream, challenging the integration, and helping turn the direct handoff model from an idea into something running against a real media server. He’s also been very supportive of XCstream continuing as an independent project, which I genuinely appreciate.

That work helped prove something important: XCstream does not need to own the media server.

A media server can simply select the source and hand it to XCstream at tune time. From there, the responsibilities become very clean:

Media server: users, lineup, EPG, scheduling, DVR and playback
XCstream: source connection, buffering, validation, outage containment, recovery and MPEG-TS continuity

That model is now working, and I think it creates a very interesting opportunity for Emby as well.

Rather than requiring an Emby-specific plugin or asking Emby to take responsibility for unreliable upstream IPTV behavior, Emby could choose the source at tune time and hand it directly to XCstream. XCstream would return one stable MPEG-TS session while Emby continues doing what it already does best.

So I’d like to extend an open invitation to @Luke, @ebrand the Emby team: if that architecture is interesting to you, I’d genuinely like to work together on a native direct integration.

To be clear, XCstream will also remain usable independently. Nobody will need to wait for a media-server integration in order to use it.

The original goal of this thread hasn’t changed:

A bad IPTV source should not automatically mean a failed playback session or a ruined recording.

What has changed is how much simpler the answer has become.

Keep the original media when it’s good.
Intervene only when it isn’t.
Keep the session alive.
Let the media server be the media server.

That’s where XCstream is heading.

And yes—I’m looking forward to finally getting this into some of your hands.