LiveTV internet streaming bitrate

[bruor 43]

I've noticed that Live TV works ok on my end if a client is in the same network, but when I try to access streams remotely it ends up pausing/buffering etc.  The server I have tested with is on a 1gb symmetrical fiber internet connection and uses hardware transcoding.

I think it is due to something specific to the way the segments are created and transferred to the client.  It almost seems like the client wants to request and get the file segments just in time, but if the server -> client transfer takes too long the client has to wait. 

Conversely, content files in my library can be streamed at much higher bitrates and suffer no playback issues.  

Is there any chance that we could get options that would allow us to separately specify an internet streaming bitrate for only Live TV content vs everything else? 

[Luke 42079]

HI, yes that is certainly possible, but can we please see an example?

How to Report a Problem

Thanks.

[bruor 43]

Ok, it will take some time to reproduce but I'll try to pull it together. 
 

[bruor 43]

So I've had users do some testing.  Issues seem to only be present on Chromecast with Google TV devices, they are all using the Android TV app.  I have noticed that the stock android app seems to be working really well lately so I will get them to test with that app on the devices.  

One user was reporting livetv issues even with the bitrate being reduced, they switched over to watching on an iPad and their experience has been great. 

I've also moved our Shield TV pro to our main living room to test since my wife says that live TV has been pausing quite a bit on our CCwGTV unit.  

I'll try doing some testing with a Roku TV next over a cellular connection and report back. 

I'll also test these Chromecast devices with Kodi and the plugin to try to pin down the issue a little further. 

 

 

 

[ebr 16184]

11 hours ago, bruor said:

So I've had users do some testing.  Issues seem to only be present on Chromecast with Google TV devices, they are all using the Android TV app.  I have noticed that the stock android app seems to be working really well lately so I will get them to test with that app on the devices. 

Hi.  Are they playing with the exact same method or is one direct playing and the other remuxing/transcoding?

[bruor 43]

If I allow them to direct stream either remotely, or locally, they exhibit the same problem.  Right now I'm transcoding the remote units down to 3mbps. And they seem to be a lot more stable but will still have issues from time to time.  Streaming live TV locally without transcode last night on my shield worked for 8+ hours and had no issues. 

[bruor 43]

The Shield TV exhibits issues from time to time.  Tonight it was showing pixelated video and stuttering during playback.  If I stopped a live TV stream and restarted it, the issue would come back after a few minutes. I rebooted the device and it has been completely stable for the last 4 hours. 

 

I purchased a Roku Express, and a Roku Stream Stick 4k.  Both seem to work relatively well with a couple exceptions.

On the Express, I have noticed one tv channel stream that it tends to stutter on during playback, the channel plays fine on other devices. 

On the stream stick 4k, I've found another channel that flat out refuses to play (transcoded or not), it shows the spinning ring (not the broken circle) over and over again. 

While I work on collecting logs for the Roku devices to submit in a new thread, I've scripted a task to reboot my Android TV devices early each morning in hopes that it will keep device side issues at bay. 

 

Edited October 12, 2023 by bruor

[bruor 43]

So interesting journey here, the channel issues I had with the Roku boxes are gone today which is great. 

I started testing 3 devices on the same channel for the last few hours here.  I read in another thread that someone had success pausing their android TV app for 30 seconds at the start of playback for a live stream. 

 

I kicked off playback on the Roku stick 4k.

On a CCwGTV I started playback but paused it for 20seconds

On my LG CX, I started playback without pausing it.  

The Roku stick dropped stopped playing 50 minutes in, the other 2 devices are still streaming the channel fine, but I noticed that the LG seems to be a little bit behind the CCwGTV when it should be about 20 seconds or so behind. 

I have no issues with streaming VOD content, but EMBY is able to pre-buffer the entire episode/movie well ahead of the playback positions.  Could these drops be caused if the client tries to overrun the available buffer in the emby server because emby isn't receiving data from the provider fast enough?  Is there a way for me to increase the pre-buffer size for live tv? 

[Luke 42079]

27 minutes ago, bruor said:

So interesting journey here, the channel issues I had with the Roku boxes are gone today which is great. 

I started testing 3 devices on the same channel for the last few hours here.  I read in another thread that someone had success pausing their android TV app for 30 seconds at the start of playback for a live stream. 

 

I kicked off playback on the Roku stick 4k.

On a CCwGTV I started playback but paused it for 20seconds

On my LG CX, I started playback without pausing it.  

The Roku stick dropped stopped playing 50 minutes in, the other 2 devices are still streaming the channel fine, but I noticed that the LG seems to be a little bit behind the CCwGTV when it should be about 20 seconds or so behind. 

I have no issues with streaming VOD content, but EMBY is able to pre-buffer the entire episode/movie well ahead of the playback positions.  Could these drops be caused if the client tries to overrun the available buffer in the emby server because emby isn't receiving data from the provider fast enough?  Is there a way for me to increase the pre-buffer size for live tv? 

 

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue. Thanks!

 

[bruor 43]

Just saw playback stop randomly across all devices and captured the logs,  been waiting for this to happen.  I had to use my computer on the LG tv so stopped playback on that device roughly 20 minutes ago,  the other 2 devices stopped playback soon after. 

 I grabbed the server log for roughly the last 4h, and the last hour or two worth of stream/transcode logs as well. 

If you need me to enable debug logging on the apps and collect logs for this from them I can try, but it may take a week or so until I can get a clean repro of the issue. 
 

embyserver.txt ffmpeg-directstream-f2b70c10-9dc4-4c72-995e-8541b1afd0ee_1.txt ffmpeg-directstream-121393d3-7b06-48f8-9331-b13cc0f60175_1.txt ffmpeg-directstream-d71b55d7-3392-4aba-ad22-64aa84e99cf6_1.txt ffmpeg-transcode-8629be06-7756-4a22-b86e-23d3ae1e1301_1.txt ffmpeg-directstream-48082bdf-b9b9-498f-bfe2-48e19ec861fb_1.txt ffmpeg-transcode-47b467fe-c268-43f8-a8ba-92e7aa11a1fa_1.txt

Edited October 12, 2023 by bruor

[Luke 42079]

Is the client on a remote connection from the server? I would try lowering the in-app quality setting and see  how that compares.

[bruor 43]

No these clients are all on my local LAN on the same subnet as the server.  The Shield TV drops and it uses a wired connection.

When I looked at the server log it seemed like it was prematurely killing the ffmpeg process for the stream server side. 

I'd like to learn a bit, what are you seeing in the logs that makes you think it is BW related on the client side? 

[bruor 43]

Started playback from the same channel.  VLC directly via the provider's URL, as well as 3 devices via Emby with this morning.  Limited them all to 4 or 5 mbps possible. 

Playback on chrome for windows froze,  VLC direct,  Roku, and CCwGTV are still playing. logs attached for the frozen stream. 

embyserver (1).txt ffmpeg-transcode-46651692-594c-4abd-a4db-7e370492e5af_1.txt

Chrome console shows that the web client is still attempting to play, but the video/audio have stopped: 

 

Edited October 13, 2023 by bruor

[bruor 43]

Playback has just stopped at the same time on the Roku and CCwGTV.   VLC direct to the provider is still running without issue.  

This seems to coincide with the timing when playback was halted. 
 

2023-10-13 09:00:38.549 Info App: ProcessRun 'StreamTranscode 721204': WaitForExitAsync failed. Killing ffmpeg process.
2023-10-13 09:00:39.050 Info SessionManager: Playback stopped reported by app Roku SG 4.0.85 playing CNN US. Stopped at 3266000 ms
2023-10-13 09:00:39.050 Info MediaSourceManager: Live stream 97194658556fdc743b47efb3d08ee14b consumer count is now 0
2023-10-13 09:00:39.050 Info MediaSourceManager: Closing live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_97194658556fdc743b47efb3d08ee14b
2023-10-13 09:00:39.050 Info SharedHttpPipelineSource: Closing SharedHttpPipelineSource
2023-10-13 09:00:39.050 Info SharedHttpPipelineSource: Deleting temp files /var/lib/emby/transcoding-temp/fd9cdf6bb1194e9093598e2368686ef5.ts
2023-10-13 09:00:39.050 Info MediaSourceManager: Live stream 06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_97194658556fdc743b47efb3d08ee14b closed successfully
2023-10-13 09:00:39.050 Info Server: http/1.1 Response 204 to host4. Time: 5507ms. http://172.16.7.111:8096/emby/Sessions/Playing/Stopped
2023-10-13 09:00:39.054 Info Trakt: Playback Stopped
2023-10-13 09:00:39.055 Info PlaybackReporting - EventMonitorEntryPoint: _sessionManager_PlaybackStop : Entered
2023-10-13 09:00:39.056 Info PlaybackReporting - EventMonitorEntryPoint: Saving final duration for Item : 6adf85ac-f5f5-55c3-bec0-ce8e7aa88316-ed5e44753e4a497b8b8c9a2e6e5fef87-3881100
2023-10-13 09:00:39.058 Info PlaybackReporting - EventMonitorEntryPoint: Removing Old Key from playback_trackers : 6adf85ac-f5f5-55c3-bec0-ce8e7aa88316-ed5e44753e4a497b8b8c9a2e6e5fef87-3881100
2023-10-13 09:00:39.218 Info Server: http/1.1 POST http://172.16.7.111:8096/emby/Sessions/Playing/Progress. UserAgent: Dalvik/2.1.0 (Linux; U; Android 12; Chromecast Build/STTE.230615.004)
2023-10-13 09:00:39.224 Info Server: http/1.1 Response 204 to host1. Time: 6ms. http://172.16.7.111:8096/emby/Sessions/Playing/Progress
2023-10-13 09:00:39.949 Info Server: http/1.1 GET http://172.16.7.111:8096/emby/videos/3881100/live.m3u8?DeviceId=0d93e50065ea3953&MediaSourceId=97194658556fdc743b47efb3d08ee14b&PlaySessionId=cc2e8f2220904b0b940f439851f837e9&LiveStreamId=06044cf0e6f93cdae5f285c9ecfaaeb4_01413a525b3a9622ce6fdf19f7dde354_97194658556fdc743b47efb3d08ee14b&VideoCodec=h264,mpeg2video,hevc,h265&AudioCodec=aac_latm,mp4a_latm,aac,mp3&VideoBitrate=4808000&AudioBitrate=192000&MaxHeight=2160&AudioStreamIndex=1&CopyTimestamps=true&SegmentContainer=ts&MinSegments=2&AllowInterlacedVideoStreamCopy=True&BreakOnNonKeyFrames=True&SubtitleStreamIndexes=-1&ManifestSubtitles=vtt&h264-profile=high,main,baseline,constrainedbaseline&h264-level=51&hevc-profile=Main,Main10&aac_latm-audiochannels=8&mp4a_latm-audiochannels=8&aac-audiochannels=8&mp3-audiochannels=8&TranscodeReasons=ContainerBitrateExceedsLimit,DirectPlayError. Connection=keep-alive, Host=172.16.7.111:8096, User-Agent=Emby/2.0.93g (Linux;Android 12) ExoPlayerLib/2.18.7, Accept-Encoding=gzip
2023-10-13 09:00:39.950 Error Server: Error processing request
	*** Error Report ***
	Version: 4.7.14.0
	Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
	Operating system: Linux version 6.2.0-33-generic (buildd@lcy02-amd64-073) (x86_64-linux-gnu-gcc-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubunt
	Framework: .NET 6.0.20
	OS/Process: x64/x64
	Runtime: opt/emby-server/system/System.Private.CoreLib.dll
	Processor count: 4
	Data path: /var/lib/emby
	Application path: /opt/emby-server/system
	System.ArgumentNullException: System.ArgumentNullException: Value cannot be null. (Parameter 'mediaSource')
	   at Emby.Server.MediaEncoding.Encoder.EncodingHelpers.AttachMediaSourceInfo(EncodingJobInfo state, MediaSourceInfo mediaSource, String requestedUrl, IFfmpegManager ffmpegManager)
	   at Emby.Server.MediaEncoding.Api.BaseStreamingService.GetState(StreamRequest request, AuthorizationInfo authorizationInfo, String manifestAbsoluteUri, Boolean requiresOutputPath, CancellationToken cancellationToken)
	   at Emby.Server.MediaEncoding.Api.Hls.BaseHlsService.ProcessRequest(StreamRequest request)
	   at Emby.Server.Implementations.Services.ServiceController.GetTaskResult(Task task)
	   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, ReadOnlyMemory`1 urlString, ReadOnlyMemory`1 localPath, CancellationToken cancellationToken)
	Source: Emby.Server.MediaEncoding
	TargetSite: Void AttachMediaSourceInfo(Emby.Server.MediaEncoding.Encoder.EncodingJobInfo, MediaBrowser.Model.Dto.MediaSourceInfo, System.String, MediaBrowser.Controller.MediaEncoding.IFfmpegManager)

 

embyserver (2).txt ffmpeg-transcode-721204fd-2359-4521-b1a1-411103d29974_1.txt ffmpeg-transcode-2a30eb4f-a531-4b97-bb3a-5496a984e10f_1.txt

[bruor 43]

I'm wondering if something else might be causing the stream issues for livetv.   The provider I use limits me to 5 active sessions to the media server.  I've noticed that ffprobe is running and seems to get a failure returned to it sometimes.  For livetv streams, how/when does emby decide to run ffprobe?   I'm wondering if it is probing during playback, and if that is the case I could see it maxing out the connections and getting a bad response from the server. 

It might also explain why strm files play without issue as they are only seem to be probed once at the start of playback. 

[bruor 43]

Playback randomly stopped on the roku, froze on the CCwGTV this time, sending debug logs from the devices for you also. 

Looks like the timestamp is around 11:26, in the log for both devices it says 
 

[q] command received. Exiting.

 

ffmpeg-transcode-ccebacbe-faf8-4e33-a0bd-95feaf4736a0_1.txt embyserver (5).txt ffmpeg-directstream-b536c4ae-a043-4156-9fce-a5ef048e36d3_1.txt

[ebr 16184]

This looks to me like the streams are cutting off at the source.

[bruor 43]

That's why I asked about ffprobe behavior.  

However, if I use xteve or threadfin in front of emby, I can stream from threadfin with VLC and emby will die while VLC keeps on ticking. 

Also, the stream don't always die at the same time.  In a couple cases, if there were transcodes to 2 different classes of devices at the same time, one class might have playback stopped while the other class keeps going for 10+ minutes.   If it was a source problem all classes of devices should have playback fail at the same time right? 

[bruor 43]

I moved my primary remote user onto a VPN tunnel so that they are using IPTV smarters to directly connect to the provider.   Emby has been streaming without issue at multiple levels for a few hours without issues. 

I've attached VLC directly to the threadfin buffer URL that emby is reading. 
I've attached VLC directly to an m3u url that it sent to my android TV device (pulled from the directstream log)
I'm watching the channel in the browser, and on 2 android TV devices, CCwGTV and an Nvidia ShieldTV pro. 

I've noticed that all the connections against emby are not using SSL, perhaps having a remotely connected client is causing some issues, but I will test adding one back into the mix at a later time.

Will keep doing some testing here to see if there's a reliable way to reproduce the issue. 

[bruor 43]

Had everything freeze up again today and looked at the VLC debug logs and there were a bunch of messages about video being skipped because it arrived too late (thought it was still playing).  It looks like other apps able to recover from provider side issues much better than Emby.  I chagned my threadfin config to use VLC as the buffer instead of ffmpeg and that seems to allow the clients to pause/start again when they hit an issue most of the time, but they still bomb out eventually. 

I'm in the process of testing a secondary provider, but so far it seems to have similar issues.  The timing of the failures is different so that rules out my network/ISP at least

Edited October 14, 2023 by bruor

[bruor 43]

One thind I've noticed in my testing is that the Android app does not have the ability to pause/rewind as it always seems to direct play Live TV.  At a minimum it should have an option similar to the Android TV app to not direct stream so that pause is available. 

[Luke 42079]

7 hours ago, bruor said:

One thind I've noticed in my testing is that the Android app does not have the ability to pause/rewind as it always seems to direct play Live TV.  At a minimum it should have an option similar to the Android TV app to not direct stream so that pause is available. 

HI, yes we are working on improving that. Thanks for the feedback.

[bruor 43]

I ended up adding a tool called hls-proxy to my setup and this seems to have resolved all of the freezing issues I was seeing.  I've been able to increase the remote bitrate for clients as well without any ill-effects. I will likely write up a how-to thread for the community when I get a little free time. 

I'm using it on 2 different servers, one where it is in front of threadfin and another where it has been put in the middle of threadfin/emby.  In both cases I have the threadfin buffer disabled. 

[bruor 43]

Follow up question,  the provider's CDN seems to lag behind at times.  I've told my hls-proxy server to send 2 chunks at a time, but I've noticed in HLS-proxy that when starting playback it emby, it will send multiple requests at the start of the stream.  This results in emby fetching 4 chunks from the server, but it starts playback frow the middle of toward the end of the fetched chunks. I've tested this by starting a channel, and seeing that there is immediately a rewind buffer available. 

Is there any way to get it to start playback at the beginning of the downloaded chunks? 

[Luke 42079]

On 10/18/2023 at 6:49 PM, bruor said:

Follow up question,  the provider's CDN seems to lag behind at times.  I've told my hls-proxy server to send 2 chunks at a time, but I've noticed in HLS-proxy that when starting playback it emby, it will send multiple requests at the start of the stream.  This results in emby fetching 4 chunks from the server, but it starts playback frow the middle of toward the end of the fetched chunks. I've tested this by starting a channel, and seeing that there is immediately a rewind buffer available. 

Is there any way to get it to start playback at the beginning of the downloaded chunks? 

Hi, the client does start playing as soon as it has something, but it's the initial live.m3u8 request that will not return until it has at least three segments.