Live TV tuning speed (sorry :-) )

[Brian_Oblivion 4]

I know this been discussed and posted about alot (including by myself) but have a question.... 

My setup is ubuntu server running docker containers of for emby/tvheadend. I don't use the tvheadend plugin in emby. I have a GPU, plenty of CPU, memory etc... I have a WinTV QUAD tuner card in it. All traffic is LAN (GB network) and there is generally on one or two users max (all local). 

I'm taking another crack at improving tuning speed. It can take up to 10 seconds to switch channels and it gets annoying.... so looking to see if I can tune things to make it better. I've tuned up tvheadend as best I can now looking at Emby (generally tvheadend direct is streaming in about a second).

Here's my question:

What is driving (fuller log snip below) this to take 3.5 seconds to complete? "SharedHttpPipelineSource: Done waiting for segments after 3501ms"?

Is this something that can be tweaked/tuned/improved? Is the "live stream buffer" configurable?

The log timestamps, looking both at tvheadend plus emby, would seem to suggest that ~4 seconds have elapsed from tuning to when the channel started playing on the TV but in reality it took about 8 seconds or so to actually see the picture.

 

####

2026-01-23 13:59:00.003 Info SharedHttpPipelineSource: Opening SharedHttpPipelineSource Live stream from Http-http://host4/x_path1_x/x_path2_x/x_path13_x?profile=pass

2026-01-23 13:59:00.003 Info HttpClient: GET http://host4/x_path1_x/x_path2_x/x_path13_x?profile=pass

2026-01-23 13:59:00.385 Info HttpClient: Http response 200 from http://host4/x_path1_x/x_path2_x/x_path13_x?profile=pass a fter 382ms. Headers Server=nginx, Date=Fri, 23 Jan 2026 18:59:00 GMT, Transfer-Encoding=chunked, Connection=keep-alive, Keep-Alive=timeout=20, Cache-Control=no-cache

2026-01-23 13:59:00.385 Info SharedHttpPipelineSource: Live stream buffer limit is 60 minutes.

2026-01-23 13:59:00.385 Info SharedHttpPipelineSource: Start waiting for the live stream buffer to fill

2026-01-23 13:59:00.385 Info SharedHttpPipelineSource: Beginning SharedHttpPipelineSource stream to /config/transcoding-temp/e59edba79afa40ec916f8effcb4f022e/{0:0000000}.ts

2026-01-23 13:59:00.385 Info SharedHttpPipelineSource: Start copying from response stream: Http-http://host4/x_path1_x/x_path2_x/x_path13_x?profile=pass

2026-01-23 13:59:03.886 Info SharedHttpPipelineSource: Done waiting for segments after 3501ms

2026-01-23 13:59:03.886 Info MediaProbeManager: ProcessRun 'ffprobe' Execute: /app/emby/bin/ffprobe -analyzeduration 3000000 -i file:"/config/transcoding-temp/e59edba79afa40ec916f8effcb4f022e/0000000.ts" -threads 0 -v info -print_format json -show_streams -show_format -show_data

2026-01-23 13:59:03.936 Info MediaProbeManager: ProcessRun 'ffprobe' Process exited with code 0

2026-01-23 13:59:03.937 Info M3UTunerHost: Live stream opened after 3934.3351ms

 

 

[Luke 42077]

Quote

would seem to suggest that ~4 seconds have elapsed from tuning to when the channel started playing on the TV but in reality it took about 8 seconds or so to actually see the picture.

HI, did it end up transcoding?

[Brian_Oblivion 4]

No, it will remux it into HLS ("compatible container") but no transcoding I can see (I do everything I can to avoid that). I even tried the "fast" tune on the android tv client (or whatever it is called). Nothing seems to help. 

I think the only real solution is predictive tuning. Given I have 4 tuners, a couple of users and about 4 different channels (frequencies) - it should tune faster. I actually tried using mux schedulers in tvheadend but it made minimal impact.

 

[Brian_Oblivion 4]

Wanted to give an update to my little rabbit hole adventure on tuning speed (sorry for the long post). TL;DR version, IMO, nothing you can do. Live with  6+ second channel tuning times :-). 

I kept digging into this and asked the question what does "slow" even mean? What could I expect in even the most perfect scenario with my tuner card to tune and start spitting out video data? i.e. what are some realistic expectations?

Before I get too much further into this, a disclaimer; I am not an expert in this domain. So it's entirely possible my analysis and methods are wrong, flawed, etc... so take all of this with a  grain of salt".

 

I wanted to test on "bare metal", i.e. take Emby/Tvheadend out of the equation entirely. So I installed some utilities on my Ubuntu server and my very basic 1st test to tune/lock a channel was less than 1 second. Hmmm.... BUT, there's more to it than that of course. So that brings the next question - how long until I get data out of the stream (mpegts data/file)? That testing showed about 1.5 seconds for data to be put on disk (*.ts file). So basically that would be the absolute, most amazingly fast tuning time I could even dream to get. BUT even not necessarily that simple either.

I noticed in my scenarios, that Emby is always spawning ffmpeg, whether it is remuxing into HLS or even direct streaming mpeg-ts to my clients (all LAN BTW).

So that led me to write a script to test these timings. I wanted to know how much time it took to tune the channel  and get .ts data and how much time is being spent with FFMPEG remuxing that .ts to HLS. What I found is the tuning time plus getting legit HLS segments was between 3-5 seconds - with MY ffmpeg parameters:
"-fflags +genpts -analyzeduration 1000000 -probesize 2000000-i -map 0:v:0 -map 0:a:0? -c:v libx264 -preset ultrafast -tune zerolatency -f segment -segment_time 3 -segment_list."

I've attached that script in case someone may find it useful. Note that it may be buggy and/or wrong in how it works or measures things. 

What I suspect are the major "controlling" parameters in the emby ffmpeg command(which is customized/optimized version of course) are these: -segment_time 00:00:03.000 -analyzeduration 3000000 and maybe the GOP parameter.  Understandable;  ffmpeg needs enough sample to figure the stream out. All together it takes about 6 seconds in the best case scenarios for a live tv stream to start.

But even when it's "direct", at least I believe it to all be configured to be direct (see screenshot), there's no getting away from 3 second+ buffering. The fire tv client is configured to allow .ts files to stream/copy, direct stream, unchecked options for deinterlacing on the server blah, blah.... the live seeking option is NOT enabled/checked. 

I installed the "diagnostics"plug in, so that, plus "stats for nerds",  seems to tell me it's direct mpegts streaming.

On the other hand, if I merely take the same URL for the tvheadend channel that emby uses (from the logs), using the same "pass" profile, into VLC player's "open network stream" on my windows machine - the stream starts within about 2 seconds. Practically instant. I can see tvheadend log the "un/subscription", as I press play/stop in VLC. To me, this confirms the 3-6 seconds of extra overhead in tuning channels is added by emby.

I'd appreciate any insight or perhaps dumb config things I'm doing wrong. It seems to me that no matter what, there's no escaping the extra 3+ seconds of overhead.

Example log snip:
2026-01-28 14:27:00.022 Info SharedHttpPipelineSource: Opening SharedHttpPipelineSource Live stream from Http-http://host5:9981/x_path1_x/x_path2_x/x_path4_x?profile=pass
2026-01-28 14:27:00.022 Info HttpClient: GET http://host5:9981/x_path1_x/x_path2_x/x_path4_x?profile=pass
2026-01-28 14:27:00.349 Info HttpClient: Http response 200 from http://host5:9981/x_path1_x/x_path2_x/x_path4_x?profile=pass after 326ms. Headers Server=HTS/tvheadend, Cache-Control=no-cache, Connection=Close
2026-01-28 14:27:00.349 Info SharedHttpPipelineSource: Live stream buffer limit is 60 minutes.
2026-01-28 14:27:00.349 Info SharedHttpPipelineSource: Start waiting for the live stream buffer to fill
2026-01-28 14:27:00.349 Info SharedHttpPipelineSource: Beginning SharedHttpPipelineSource stream to /transcode-temp/transcoding-temp/d2582090e9454d7b97383e4e0e62233b/{0:0000000}.ts
2026-01-28 14:27:00.349 Info SharedHttpPipelineSource: Start copying from response stream: Http-http://host5:9981/x_path1_x/x_path2_x/x_path4_x?profile=pass
2026-01-28 14:27:03.849 Info SharedHttpPipelineSource: Done waiting for segments after 3500ms
2026-01-28 14:27:03.849 Info MediaProbeManager: ProcessRun 'ffprobe' Execute: /app/emby/bin/ffprobe -analyzeduration 3000000 -i file:"/transcode-temp/transcoding-temp/d2582090e9454d7b97383e4e0e62233b/0000000.ts" -threads 0 -v info -print_format json -show_streams -show_format -show_data
2026-01-28 14:27:03.934 Info MediaProbeManager: ProcessRun 'ffprobe' Process exited with code 0
2026-01-28 14:27:03.935 Info M3UTunerHost: Live stream opened after 3912.8743ms
2026-01-28 14:27:03.935 Info LiveTV: Returning mediasource streamId edbb98dcb122a538e915d8dcb6200c41, mediaSource.Id edbb98dcb122a538e915d8dcb6200c41, mediaSource.LiveStreamId

test_hls_tuning_pseudo_emby_style.sh

Edited January 28 by Brian_Oblivion

[denz 501]

You discovered what we have been complaining for ever but it falls on death ears. There is a dev that developed improvements but it all looks like his work was thrown in the trash and it will never see the light of day. I assumed it wasn’t opensourced as it was paid work byt Emby 
 

 Its crazy that WMC could tune in a second 20 years ago and emby is still not able with all the advancment in software.frameworks. Opensourcing  that would mean it would have been likely picked up by the opensource competitor and most of us would have moved.

[Brian_Oblivion 4]

Thanks...

I will add this, and the real emby devs can correct me if I'm wrong, all HTTP MPEGTS streams will take AT LEAST 3.5 seconds to tune. That's where you start from. In the real world you can at a second or 2 for it to show up on a client best case scenario (I average about 8 total). There almost certainly seems to be a hardcoded 3.5 second buffer in there.  And, oddly, from my testing, seems like HLS channel streams can be worse. This is because it *appears* emby will buffer X segments. If segments are 2 seconds long and it buffers 3 of them etc... it takes even longer. 

What I've learned (which I could be wrong), is that HLS segments split on i-frames and the intervals of those vary by broadcasters. So it's certainly going to be 3-6 seconds from a 'cold tune' to get legit HLS segments from OTA channels. 

Bottom line is, ANY media server that is "proxying" a stream from TVH, must buffer it so it can figure out what the stream is (video/audio codec etc) to send it to clients. And ffmpeg needs a solid 1-2 seconds at a minimum (IMO). 

If you want super fast tuning, you have to go after the mpegts stream directly via direct http connection to tvheadend... i.e. the "VLC player" way.  The trade off there is you lose all the cool features of emby :-).

The only other alternative I can think of is predictive or "cached" tuning. Keep multiple streams constantly connected/tuned to tvheadend - dumping the video data if no user is requesting the channel. Maintain an LRU buffer of channel streams and hand them out if a user requests it and you have it..... otherwise make TVH tune it and spin up a new stream (easier said than done ).The tvheadend plugin for Kodi seems to do something like this, I'm currently exploring that option.

 

I'm also exploring if I could extend/create a tvh plugin based upon the old TVH plugin Luke has out there on github to try to do this stream cache/predictive tuning thing - but I would guess no matter what is done inside the plug in, the http stream would go through sharedhttppipelinesource - making the effort moot. 

 

All in all, it's a challenging technical problem and given the breadth of hardware&platforms emby supports - it can be daunting. I'll also say Emby's live tv implementation is the #1 reason I moved to it from plex and bought a lifetime pass. So I hope the devs that live and breathe this stuff have alot of great ideas in the dev pipeline to make quantum leap improvements :-). 

 

Edited January 30 by Brian_Oblivion