2026-02-05, 12:26 AM
Hello!
Long time Emby user; 1st time Jellyfin user here :-). Apologies for the super-mega post as my 1st one; jumping into the deep end of the "pool" head first!
I wanted to post about a "not-so-little" plug in project I've been developing to see what the Jellyfin community thinks about it. Curious if anyone would even care about this. So if you don't care about "channel zapping" (aka quickly switching between live channels) - then read no further.
The genesis of the idea was this. For a *VERY* long time I've been annoyed with the amount of time it took *Emby* to tune live tv/OTA channels... even when "direct" streaming them. Jellyfin is faster when direct streaming, so much so it's hardly worth complaining about, nevertheless it's annoying to me - particularly when remuxing/transcoding gets into the mix. Some devices can't stream mpegts directly very well, or at all. So remuxing to different containers HLS (et al) and/or transcoding,(e.g. deinterlacing) is performed. When remux/transcoding gets into the mix, it gets really painfully slow - taking at least 5 seconds+ to tune a channel (not all that surprising). Other media servers have the similar issues, so not unique to any one in the particular.
So rather than complain about it, I decided to try and do something about it.
So why Jellyfin and not Emby? Because Jellyfin is open source, I needed to understand the source code and, as it stands now, I needed to make changes to the server code (optional interfaces, some logic changes) for my plug in to work. Trying to be generic enough for other plugin development that has nothing to do with this, so it can get it's hooks into the tuning architecture - at least that's the goal!
I started hacking at this not expecting it to work but alas I've got a working POC afterall! I am caching/pooling both direct streaming connections and those that are using "process" connections (ffmpeg, not that I care, streamlink would probably work also). Caching direct streams has a minimal, but noticeable impact. Caching ffmpeg streams on the other hand has a dramatic improvement. Once you have tuned channels in the pool; "zapping"/switching between channels is practically instant - both in the web client, android mobile app and AndroidTV client (all I've tested thus far).
I run an Ubuntu server with docker containers for tvheadend (TVH), Jellyfin and including a container this for effort. I have a WinTv quad tuner card in there. Tvheadend uses the tuner card and streams to my media server(s) which then streams to clients... all of which are "local" (like in the same house). This is very much a "home media" server scenario versus serving lots of remote users etc.
The idea is, since I have tvheadend with 4 tuners that are not fully utilized, why not cache the connection streams from Jellyfin to TVH, dump the video segment data to disk and have them ready to instantly stream when the user tunes back to the channel? Thus channels are always "tuned". There has to be rules on pool eviction and purging of course - I'll avoid getting into the weeds of that for now. I'll just say I put a considerable amount of work/time into working all that out (still am!).
The plug in is currently called "warm pool" which is a very un-creative name... and probably will change :-). The intent is for it to be IPTV tuner agnostic, thus can be used with any http streams.... but I am focusing on optimizing it for TVH. This means it has to be aware that it's a TVH server because of how tuners/muxes work there. TVH will tune a mux, i.e. a channel, but that channel can have sub channels (5.1 5.2 5.3).... ALL of those sub channels only consumes *1* tuner. The advantage here in the "home server" world where you may have 6-ish "frequencies" (aka channels) you're typically tuning on a regular basis - is you just keep those tuned "ready for action". Basically, you can "insta-tune" them after paying the penalty 1 time (though I'm considering have a "pre-warmer" for most used channels so you'll never notice it).
At any rate. I can blather on about the technical details forever. Bottom line is; after 'initial tuning" of channels, switching back across those channels is practically instant. But a picture paints a thousand words so here's a some screenshots and a video demo.
I've attached a few screenshots of the plug config page
and there is a link below to a video showing it in action. Nothing edited or sped up; no BS. A real time capture of it working. The config settings are at the top and the somewhat clunky monitoring/metrics are at the bottom (this needs work for sure). Then there's a split tab showing the channel video stream on one side and my tvheadend console on the other to show what's happening there. The thing to note on tvheadend is the tuners starting up and then the subs increasing when "sub channels" are tuned(5.1 5.2 5.3 etc).
Then I basically tune a couple of channels, they take forever to start at 1st due to transcoding (like to work on that too :-)) - then I flip back and forth between them. Then a do a couple more channels and subchannels, flip around demonstrating how fast they tune back. I also go over to the plugin settings to look at the metrics showing what's in the pool. Also note what happens when I run out of tuners. The plug in is monitoring "tuner pressure", checking tvheadend if the tuners are full. If they are, like I show in the demo, it will run a special eviction to purge of inactive streams in the pool to free up a tuner WHEN a user tries to tune on a 5th tuner (I have a max of 4 in my particular case).
This is via the Jellyfin webclient obviously but you'll have to take my word for it that via the AndroidTV client is just as snappy (it's fun to hit that back arrow or the context/overlay channel guide to *instantly* flip between channels :-)). This is happening because the streams in the pool keep running when "de-tuned" and then get served back to the client when "re-tuned".
Link to the demo video. This will expire in a few days.
Plugin Demo Link
Right now, I'm tickled pink. For my use case I basically will have my favorite OTA channels tuned 24/7 so they will tune instantly. So I'm happy to just have this as my "own thing" if this isn't of much interest folks. I'm sure the process of refinement to get these changes worthy of a Jellyfin core PR will be a lot of work I'd imagine (and rightfully so).
Disclaimer: I am a total noob to this codebase and given this cuts across the core of Jellyfin - it's quite complicated. I'm sure I'm missing lots of stuff, have bugs to uncover and may hit a brick wall exceeding what a "plugin" should be doing.
Thanks!
Long time Emby user; 1st time Jellyfin user here :-). Apologies for the super-mega post as my 1st one; jumping into the deep end of the "pool" head first!
I wanted to post about a "not-so-little" plug in project I've been developing to see what the Jellyfin community thinks about it. Curious if anyone would even care about this. So if you don't care about "channel zapping" (aka quickly switching between live channels) - then read no further.
The genesis of the idea was this. For a *VERY* long time I've been annoyed with the amount of time it took *Emby* to tune live tv/OTA channels... even when "direct" streaming them. Jellyfin is faster when direct streaming, so much so it's hardly worth complaining about, nevertheless it's annoying to me - particularly when remuxing/transcoding gets into the mix. Some devices can't stream mpegts directly very well, or at all. So remuxing to different containers HLS (et al) and/or transcoding,(e.g. deinterlacing) is performed. When remux/transcoding gets into the mix, it gets really painfully slow - taking at least 5 seconds+ to tune a channel (not all that surprising). Other media servers have the similar issues, so not unique to any one in the particular.
So rather than complain about it, I decided to try and do something about it.
So why Jellyfin and not Emby? Because Jellyfin is open source, I needed to understand the source code and, as it stands now, I needed to make changes to the server code (optional interfaces, some logic changes) for my plug in to work. Trying to be generic enough for other plugin development that has nothing to do with this, so it can get it's hooks into the tuning architecture - at least that's the goal!
I started hacking at this not expecting it to work but alas I've got a working POC afterall! I am caching/pooling both direct streaming connections and those that are using "process" connections (ffmpeg, not that I care, streamlink would probably work also). Caching direct streams has a minimal, but noticeable impact. Caching ffmpeg streams on the other hand has a dramatic improvement. Once you have tuned channels in the pool; "zapping"/switching between channels is practically instant - both in the web client, android mobile app and AndroidTV client (all I've tested thus far).
I run an Ubuntu server with docker containers for tvheadend (TVH), Jellyfin and including a container this for effort. I have a WinTv quad tuner card in there. Tvheadend uses the tuner card and streams to my media server(s) which then streams to clients... all of which are "local" (like in the same house). This is very much a "home media" server scenario versus serving lots of remote users etc.
The idea is, since I have tvheadend with 4 tuners that are not fully utilized, why not cache the connection streams from Jellyfin to TVH, dump the video segment data to disk and have them ready to instantly stream when the user tunes back to the channel? Thus channels are always "tuned". There has to be rules on pool eviction and purging of course - I'll avoid getting into the weeds of that for now. I'll just say I put a considerable amount of work/time into working all that out (still am!).
The plug in is currently called "warm pool" which is a very un-creative name... and probably will change :-). The intent is for it to be IPTV tuner agnostic, thus can be used with any http streams.... but I am focusing on optimizing it for TVH. This means it has to be aware that it's a TVH server because of how tuners/muxes work there. TVH will tune a mux, i.e. a channel, but that channel can have sub channels (5.1 5.2 5.3).... ALL of those sub channels only consumes *1* tuner. The advantage here in the "home server" world where you may have 6-ish "frequencies" (aka channels) you're typically tuning on a regular basis - is you just keep those tuned "ready for action". Basically, you can "insta-tune" them after paying the penalty 1 time (though I'm considering have a "pre-warmer" for most used channels so you'll never notice it).
At any rate. I can blather on about the technical details forever. Bottom line is; after 'initial tuning" of channels, switching back across those channels is practically instant. But a picture paints a thousand words so here's a some screenshots and a video demo.
I've attached a few screenshots of the plug config page
Then I basically tune a couple of channels, they take forever to start at 1st due to transcoding (like to work on that too :-)) - then I flip back and forth between them. Then a do a couple more channels and subchannels, flip around demonstrating how fast they tune back. I also go over to the plugin settings to look at the metrics showing what's in the pool. Also note what happens when I run out of tuners. The plug in is monitoring "tuner pressure", checking tvheadend if the tuners are full. If they are, like I show in the demo, it will run a special eviction to purge of inactive streams in the pool to free up a tuner WHEN a user tries to tune on a 5th tuner (I have a max of 4 in my particular case).
This is via the Jellyfin webclient obviously but you'll have to take my word for it that via the AndroidTV client is just as snappy (it's fun to hit that back arrow or the context/overlay channel guide to *instantly* flip between channels :-)). This is happening because the streams in the pool keep running when "de-tuned" and then get served back to the client when "re-tuned".
Link to the demo video. This will expire in a few days.
Plugin Demo Link
Right now, I'm tickled pink. For my use case I basically will have my favorite OTA channels tuned 24/7 so they will tune instantly. So I'm happy to just have this as my "own thing" if this isn't of much interest folks. I'm sure the process of refinement to get these changes worthy of a Jellyfin core PR will be a lot of work I'd imagine (and rightfully so).
Disclaimer: I am a total noob to this codebase and given this cuts across the core of Jellyfin - it's quite complicated. I'm sure I'm missing lots of stuff, have bugs to uncover and may hit a brick wall exceeding what a "plugin" should be doing.
Thanks!