A new approach to making IPTV behave more like traditional tuners

[EODCrafter 186]

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 1]

I am also curious to test this project out with Emby

[PowerCC 41]

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.

[ExploitPanda 1]

Excited to test out the first version of XCstream

[PowerCC 41]

A lot has happened with XCstream since my last update.

0.9.9-beta is still in development and qualification, so there isn’t a public download for this build yet.

Before I get into the changes, I should probably explain one of XCstream’s core concepts because I use the word Slate a lot.

What is Slate?

When an IPTV provider completely stops delivering usable media, XCstream eventually reaches a point where there is nothing left to preserve.

Instead of simply allowing the downstream stream to die, XCstream can temporarily replace the failed upstream media with a synthetic MPEG-TS stream that I call Slate.

Think of it as a controlled outage bridge.

The provider may be dead behind XCstream, but the media server downstream can continue receiving valid MPEG-TS while XCstream works on getting the real source back.

Conceptually:

Healthy Provider
↓
Provider fails
↓
XCstream can no longer safely preserve the source
↓
Slate keeps protected MPEG-TS flowing downstream
↓
XCstream works on recovering the real provider

Provider video itself is still pass-through. XCstream does not transcode the provider feed. Only the synthetic Slate is encoded.

That distinction becomes pretty important in 0.9.9.

One thing I’ve learned pretty clearly over the last few days is that the behavior I originally built for recording is not always the behavior you want when somebody is just sitting there watching Live TV.

XCstream was built from day one around one basic idea:

Protect the upstream source and salvage as much usable video as possible.

That works really well for DVR.

If a provider stops sending usable video for 10 or 15 seconds but there’s a decent chance it will recover, I would rather XCstream wait and save that material than instantly give up and throw Slate into the recording.

That was always the priority.

But for Live TV?

Nobody wants to stare at a frozen football game for 15 seconds while XCstream patiently waits to see if the provider is going to wake back up.

So v0.9.9-beta is getting a new Streaming Priority setting.

Current XCstream Setup UI on macOS ARM64 (v0.9.8-beta). 0.9.9-beta expands this with Streaming Priority and additional recovery controls.

DVR Priority — Default

This keeps the current XCstream behavior.

It is intentionally more patient with bad providers.

XCstream gives the source more opportunity to recover naturally before deciding the stream is really gone and moving into recovery/Slate.

The goal is simple:

Save as much of the original program as possible.

Live TV Priority

Same exact recovery engine.

No second Live TV engine.

It just changes how aggressive XCstream is.

It checks stream progression more frequently, declares a real stall much sooner, waits less for spontaneous recovery, retries the provider sooner, and uses a smaller initial buffer so playback can get moving faster.

A quick hiccup can still recover naturally.

A genuinely dead source should move toward recovery/Slate much faster instead of sitting there frozen forever.

That gives me both behaviors without ruining the recording-first logic XCstream was originally built around.

The other big thing coming in 0.9.9 is Session-Matched Slate.

Right now XCstream has validated generic H.264 and HEVC Slate available when the real source is gone.

That works, but it is still a different media stream.

With 0.9.9, once XCstream has identified the source profile, it can prepare Slate that matches the stream much more closely:

• video codec
• resolution
• frame rate
• pixel format / bit depth
• audio codec
• sample rate
• channel layout

So if I’m watching a 1080p H.264 / AC3 channel and the provider dies, XCstream can use Slate that is much closer to what the decoder was already seeing.

The idea is to avoid unnecessary codec changes, resolution changes, audio changes, decoder resets, etc. just because the provider fell over.

The Slate is generated in the background while the source is healthy.

And I’m not generating one for every channel.

If several channels use the same effective media profile, XCstream generates it once, validates it, caches it for the life of the running process and reuses it.

Different channel. Different provider. Different tuner.

Doesn’t matter.

If the media contract matches, reuse it.

And just to be clear:

Provider video is still NOT being transcoded.

Provider video stays pass-through MPEG-TS.

Only the synthetic Slate gets encoded.

I’m also adding an experimental option called Protected Slate Handoff.

Getting into Slate cleanly is one problem.

Getting back out of Slate cleanly is another.

A provider can start sending again, look good for two seconds, and immediately die again.

I don’t want this:

Slate → Live → dead → Slate → Live → dead

That’s ugly.

So with Protected Handoff enabled, XCstream can keep Slate publicly playing while the real provider recovers privately in the background.

The recovered source has to prove that it is actually healthy before XCstream puts it back on the public stream.

Basically:

Healthy Live
↓
Provider dies
↓
Matched Slate
↓
Provider recovers privately
↓
XCstream proves MPEG-TS delivery and the media clock are healthy
↓
Controlled return to Live

If the recovered source still looks questionable, XCstream leaves Slate up and keeps working on the real source behind it.

That feature is going to stay Disabled by default initially.

The return-to-live path is one of the touchiest parts of the engine and I want to beat the hell out of it before I make it normal behavior.

One thing I also want to make really clear because XCstream has changed quite a bit since I started this thread:

XCstream is not an HLS/DASH segmenter.

It does not create the HLS segments your media server uses.

That belongs downstream.

XCstream’s job is:

Provider
↓
XCstream protects / buffers / validates / recovers
↓
continuous protected MPEG-TS
↓
Kernel Media Server / Emby / Jellyfin / Channels DVR Server / Plex whatever consumes it

The media server still owns playback, HLS/DASH packaging, DVR scheduling, users, libraries, clients, etc.

XCstream owns the ugly part upstream.

If the provider freezes, starves, stops advancing video while the connection still looks alive, wakes back up, dies again, or needs the producer completely restarted, XCstream is supposed to fight through that before the media server ever has to care.

That is still the whole point of the project.

0.9.9 just makes XCstream smarter about the fact that:

protecting a recording and protecting somebody watching Live TV sometimes need different timing.

Still testing.

Still breaking things.

Still abusing some absolutely horrific IPTV streams because they make great test subjects. 

[EODCrafter 186]

I think people just want to know where they can get a copy of the binary.....

[Fyb3roptik 4]

The initial release will come packed with Kernel Media Server 0.9.0 when it releases soon. You can install Kernel via Docker, Apt/Yum, or Bare metal from Downloads on the website

[horstepipe 433]

will this tool also be suitable as a middleware between Dispatcharr and Emby?

BR

[EODCrafter 186]

3 hours ago, horstepipe said:

will this tool also be suitable as a middleware between Dispatcharr and Emby?

BR

It accepts m3u input along with xml. Hope that helps. 

[horstepipe 433]

On 10/6/2026 at 8:13 PM, Fyb3roptik said:

The initial release will come packed with Kernel Media Server 0.9.0 when it releases soon. You can install Kernel via Docker, Apt/Yum, or Bare metal from Downloads on the website

Hey

Does it support .strm files?

[Fyb3roptik 4]

37 minutes ago, horstepipe said:

Hey

Does it support .strm files?

Yes it does! You can enable VODs from providers from within Kernel and it creates libraries for you with those strm files and they play natively.

[mwongjay 96]

I'm interested in seeing a comparison between this and Dispatcharr. Both seem fairly even if you do advanced configuration of Dispatcharr.

Looping image on failures 

Could Not Dispatch Dispatcharr plugin

Stream resiliency

Dispatcharr's exception handling around network errors when using the default ffmpeg stream profile didn't work well for me and had downstream affects to Emby. Dispatcharr has recently updated the ffmpeg arguments to improve resiliency, but prior to that release a few weeks ago, I found more stability creating separate stream profiles for iptv, iptv 4k, and ota (HDHR tuners) to improve resiliency and reconnections rather than allowing the stream to fail and have Dispatcharr manage the failures. Additionally, configuring the proxy settings further improves reliability. 

My mpeg-ts over http profile:

-hide_banner -nostdin -fflags +genpts+discardcorrupt -dts_delta_threshold 2 -rw_timeout 20000000 -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_on_network_error 1 -reconnect_on_http_error 5xx -reconnect_delay_max 3 -reconnect_delay_total_max 15 -user_agent "{userAgent}" -i "{streamUrl}" -map 0:v:0 -map 0:a:0? -sn -dn -c:v copy -c:a copy -bsf:v dump_extra=freq=keyframe,h264_metadata=aud=insert -mpegts_flags +resend_headers+initial_discontinuity -muxdelay 0 -f mpegts pipe:1

My hls stream profile:

-hide_banner -loglevel warning -nostdin -fflags +genpts+discardcorrupt -dts_delta_threshold 2 -rw_timeout 20000000 -reconnect 1 -reconnect_streamed 1 -reconnect_on_network_error 1 -reconnect_on_http_error 429,5xx -reconnect_delay_max 3 -reconnect_max_retries 3 -reconnect_delay_total_max 15 -user_agent "{userAgent}" -f hls -live_start_index -3 -http_persistent 1 -http_multiple 1 -seg_max_retry 2 -i "{streamUrl}" -map 0:v:0 -map 0:a:0? -sn -dn -c:v copy -c:a copy -bsf:v dump_extra=freq=keyframe -mpegts_flags +resend_headers+initial_discontinuity -muxdelay 0 -flush_packets 1 -f mpegts pipe:1

Observability

This is where I see the value in XCstream. Dispatcharr has the Stats page and logs that has a lot of overlap, but I'd love to see some of the telemetry you have in Dispatcharr

Configurability

I think Dispatcharr has the upper hand here. You have the ability to create and map stream profiles and output formats at a granular or macro level

Curious what others think

[PowerCC 41]

Thanks for the detailed comparison. Dispatcharr is certainly more configurable when it comes to stream profiles, source management, and output formats. No argument there.

The fundamental difference is how XCstream handles upstream media failure, not how FFmpeg is configured.

Your FFmpeg arguments address network reconnection, corrupt packets, and transport behavior. XCstream takes a different approach by independently supervising each active FFmpeg pipeline, measuring both committed MPEG-TS output and media-clock progression. A provider can maintain an active HTTP connection, and FFmpeg can remain running, while usable media has stopped advancing.

XCstream recognizes this distinction. It tolerates recoverable stalls without unnecessarily restarting the stream, but when a failure becomes sustained, it can activate source-matched Slate to maintain downstream continuity while recovering the upstream, without transcoding the provider's video.

To put that into perspective, I recently recorded an 88-minute movie from an exceptionally unstable provider. XCstream absorbed 23 stalls and encountered a sustained outage lasting approximately 49 seconds. Rather than losing the recording, XCstream activated source-matched Slate for approximately 14 seconds, recovered the upstream, and continued recording. The damaged footage remained damaged, of course, but the recording survived. That's the distinction between recovering a connection and preserving an active recording session.

As for observability, the telemetry isn't simply for diagnostics. It's the same information XCstream uses to make those recovery decisions in real time.

So while there's certainly overlap, the architectural approaches are different. Dispatcharr provides extensive control over stream management and configuration, while XCstream specializes in independently monitoring media health and preserving downstream continuity. They're not necessarily competing solutions.

Edited October 13 by PowerCC

[arrbee99 1916]

Just wondering, as a mere mortal, how easy would this be to actually use ? I've seen Docker and I don't know what else mentioned. For me anything beyond copy this dll isn't really going to happen.

[PowerCC 41]

Fair question! You won't need Docker, and XCstream isn't an Emby plugin or DLL.

XCstream is a standalone application that runs directly on Windows, macOS, and Linux. Simply download the version for your operating system, launch it, and follow the built-in Quick Setup to configure your source. Once configured, just add XCstream's generated M3U playlist to Emby as your Live TV source.

There's no need to understand FFmpeg or worry about configuring command-line arguments. XCstream handles all of that internally.

Thanks to a great partnership with the developer of Kernel Media Server (KMS), XCstream will also be distributed through KMS as a standalone application, with the option to integrate directly with Kernel Media Server.

The integration goes well beyond simplifying setup. Through bi-directional communication, KMS and XCstream will coordinate stream requests, tuner allocation, availability, and release, helping ensure tuners are assigned when needed and properly freed when sessions end. This allows KMS to handle stream requests and tuner management while XCstream focuses on what it does best: monitoring upstream media health, recovering from failures, and maintaining stream continuity.

The result is a much more seamless experience, with less manual configuration, better coordination of available tuners, and a simpler way to get everything running together. For KMS users, getting XCstream up and running should be a breeze!

I won't pretend it's quite as simple as copying a DLL, but ease of use has been an important consideration throughout development. My goal is to make XCstream approachable for everyday users while retaining the advanced capabilities that more technical users appreciate.

Edited October 13 by PowerCC

[Fyb3roptik 4]

Kernel Media Server also has a wizard. 0.9.0 will feature an import tool for Plex/Jellyfin users too

[arrbee99 1916]

Thanks. Sounds promising. Hopefully I'll be able to have a go with this supplying IPTV to Emby like I use NextPVR to supply DVB-S to Emby.

[PowerCC 41]

That's exactly the idea! Much like you're using NextPVR to bring DVB-S into Emby, XCstream provides an M3U interface for bringing your sources into Emby, with the added benefit of continuous stream monitoring and automatic recovery when the upstream misbehaves.

[TMCsw 307]

This does sound promising, but I'm wondering about "Pricing?"

A quick look at KMS free/Pro, I don't see why I would want it to transcode anything when I already have Emby Premiere to take a raw .ts and transcode it accordingly ?

Edited October 13 by TMCsw

[PowerCC 41]

Great questions!

Regarding pricing, we're still working through the distribution and licensing details, including how XCstream will be offered through Kernel Media Server. I'd rather not announce anything prematurely, but I'll share more as we get closer to release.

As for transcoding, you're absolutely right! If you already have Emby Premiere, there's no reason to duplicate that functionality.

XCstream doesn't transcode the upstream video. In fact, I deliberately moved away from transcoding during development. XCstream uses stream copy to preserve the original source while independently monitoring media health, managing upstream failures, and maintaining downstream continuity.

Emby can continue handling transcoding exactly as it does today.

XCstream is also a standalone application, so you can use it directly with Emby through its M3U interface. The KMS partnership adds another distribution and integration option, including coordinated tuner management and streamlined configuration.

Ultimately, XCstream's purpose isn't to replace what Emby already does well. It's to help ensure Emby receives a continuous, resilient stream in the first place.

[horstepipe 433]

So are we talking about weeks or months until we finally can try it out?

[Fyb3roptik 4]

Kernel Media Server: a Plex/Jellyfin/Emby alternative built for Live TV

Kernel is a media server designed to replace Emby, Jellyfin, and Plex. I'd love to hear what the community thinks of the Live TV setup in particular. VOD and library management are coming along nicely, and the goal for 1.0 is full feature parity with Plex and Jellyfin on the VOD side, then going well beyond them on Live TV.

What Kernel already does:

• Xtream Codes support, including VOD and .strm files
• HLS/DASH ladder output: feed it a 1080p source and it generates lower-quality renditions too (720p, a reduced-bitrate 1080p, whatever you choose)
• Custom EPG categories that show up as tabs in both the guide and channels screens, so you organize live TV your way

Feedback, feature requests, and bug reports are all welcome.

[horstepipe 433]

On 10/6/2026 at 8:13 PM, Fyb3roptik said:

The initial release will come packed with Kernel Media Server 0.9.0 when it releases soon. You can install Kernel via Docker, Apt/Yum, or Bare metal from Downloads on the website

 

2 hours ago, Fyb3roptik said:

Kernel Media Server: a Plex/Jellyfin/Emby alternative built for Live TV

Kernel is a media server designed to replace Emby, Jellyfin, and Plex. I'd love to hear what the community thinks of the Live TV setup in particular. VOD and library management are coming along nicely, and the goal for 1.0 is full feature parity with Plex and Jellyfin on the VOD side, then going well beyond them on Live TV.

What Kernel already does:

• Xtream Codes support, including VOD and .strm files
• HLS/DASH ladder output: feed it a 1080p source and it generates lower-quality renditions too (720p, a reduced-bitrate 1080p, whatever you choose)
• Custom EPG categories that show up as tabs in both the guide and channels screens, so you organize live TV your way

Feedback, feature requests, and bug reports are all welcome.

 

but this will be implemented in v.0.9 which isn't released yet?

[EODCrafter 186]

26 minutes ago, horstepipe said:

 

 

but this will be implemented in v.0.9 which isn't released yet?

I think they are separate programs, not implementation.