Buffering Video All of a Sudden

[Netbug 26]

App: Emby for LG 1.0.39

Server: 4.7.14.0 running on unRAID

Hardware Information

• Motherboard: ASUSTeK COMPUTER INC. X99-A II , Version Rev 1.xx
• Processor: Intel Core i7-6850K CPU @ 3.60GHz
• RAM: 32GB
• SATA Extender: Supermicro AOC-SASLP-MV8 SATA Extender
• Hot-swap Bays: SuperMicro CSE-M35T-1B (x 3)
• Power Supply: CORSAIR Enthusiast Series TX750M
• USB (unRAID): Lexar JD Firefly 8GB

 

• Hard Drives:
• Parity    WDC_WD80EFAX-68KNBN0_VDHBX7VD - 8 TB (sdb)
• Disk 1    WDC_WD20EADS-00R6B0_WD-WCAVY5374796 - 2 TB (sdf)
• Disk 2    WDC_WD30EZRX-19D8PB0_WD-WMC4N0J7D8TT - 3 TB (sdd)
• Disk 3    WDC_WD20EARS-00MVWB0_WD-WCAZA9034298 - 2 TB (sde)
• Disk 4    WDC_WD80EFAX-68KNBN0_VDH2MGVD - 8 TB (sdh)
• Disk 5    ST4000DM005-2DP166_WGY0E53A - 4 TB (sdj)
• Disk 6    ST3000DM001-1CH166_W1F23145 - 3 TB (sdm)
• Disk 7    WDC_WD30EZRX-00SPEB0_WD-WCC4E0NP7NLR - 3 TB (sdl)
• Disk 8    ST8000DM004-2CX188_ZR128XVM - 8 TB (sdk)
• Disk 9    ST4000DM005-2DP166_WDH2S61F - 4 TB (sdg)
• Disk 10    ST4000DM004-2CV104_ZFN0BNMN - 4 TB (sdi)
• Disk 11    ST8000DM004-2CX188_ZCT3VH40 - 8 TB (sdc)    
• Cache INTEL_SSDPEKNW512G8_PHNH929303YD512A - 512 GB (nvme0n1)
• Flash JD_FireFly - 8 GB (sda)

 

 

For some reason, content I'm watching has started to buffer at random.

I'm trying to figure out how I can determine if it's a hard drive issue, processor, or network problem and I'm not quite sure to start.

I'll be watching a show, and all of a sudden it will just freeze for up to 2 minutes. It will then start playing for a bit, then freeze.

One thing I'm noticing, is on the Emby dashboard, there's a pair of indicator lines, one red, and one green. I believe these are the playback position (green) and where it's buffered to (red). It seems that when the green catches the red, the problem occurs (screenshot attached).

Where can I start to look for the bottleneck?

Thanks.

embyserver.txt ffmpeg-remux-e4213cb5-8486-4181-bbb4-4eeb6c8f6ffa_1.txt

Edited January 17, 2024 by Netbug

[Luke 42080]

Hi, does it happen with content that direct plays?

[Netbug 26]

I'm honestly not sure. I'm not great at this. Is there a way I can force something to direct play to test it?

I did just change over and play through an Google Chromecast Ultra using a Samsung S22 and the Android Emby app and the problem did NOT occur, so I'm wondering if it's something to do with the Emby LG app.

What other information can I gather to help you guys?

[JuJuJurassic 49]

11 hours ago, Netbug said:

I'm honestly not sure. I'm not great at this. Is there a way I can force something to direct play to test it?

I did just change over and play through an Google Chromecast Ultra using a Samsung S22 and the Android Emby app and the problem did NOT occur, so I'm wondering if it's something to do with the Emby LG app.

What other information can I gather to help you guys?

Hi Netbug,

I had this exact problem, with an LG client. I spent ages looking at it, have a look at my posts, and then for some reason, it just started working again. I never did get to the bottom of it. But do read my posts it will hopefully save you some time. Here's the url;

 

 

 

[visproduction 315]

My guess is transcoding surround sound audio can cause possibly TCP/IP ack packet out of order so your TCPWIN rejects the converted sequence and requests the packets again, thus causing TCP packets to be resent.  If you test the same media with AC3 converted to AAC audio, it will probably not buffer.  It's possible to adjust your TCPWIN value upwards, but typically that setting is automated by OS nowadays to work fine for most long distance host that has a lot of HOPS.   This problem could also show up locally even with hardly any delay from the server to the user, because the playback in a browser can still have out of order packets coming from surround sound encode. If it is an OS out of order issue, then it may not matter if you are remote, local or even with a different app.  The hickup is coming from the OS, perhaps.

WIndows use to set TCPWIN at a multiple that allowed about 16 ack packets to go by before it was considered to be out of order and then request the entire group of TCP packets again.  Then Windows moved to a sliding TCPWIN setting with 'Autotune'.  The problem with this is it is never setup to handle extreme out of order ack packets that can happen with surround sound encoding into cache plus the high bitrate video encoding stream at the same time.  If you have Windows 64 bit, you can try this guide with the TCP optimization tool and make the settings seem like you have a slower connection.  That will hopefully adjust the TCPWIN timeout longer and allow, out of order ack to go higher in number before they are rejected in a group and requested again.  Setting the options too slow can cause too much overhead to handle all the tcp packet cache.  It's tricky.  It's just my guess that your encoding settings are set so high in bitrate that the number of packets slip out of order and the OS TCP service throws out the red flag, requests groups of TCP packets again and makes the playback stutter.

You could try turning off autotuning as administrator, if you have a Windows server and see if that makes any difference.

netsh int tcp set global autotuninglevel=disabled

At this point, you’ll have disabled Auto-Tuning. If you want to re-enable it, run the following command:

netsh int tcp set global autotuninglevel=normal

Use this to see the results: netsh interface tcp show global

===

Maybe don't set encoding so high to start with and convert AC3 to AAC before adding content to your library.

https://helpdeskgeek.com/how-to/how-to-optimize-tcp-ip-settings-in-windows-10/

Edited January 17, 2024 by visproduction

[Luke 42080]

16 hours ago, Netbug said:

I'm honestly not sure. I'm not great at this. Is there a way I can force something to direct play to test it?

 

By temporarily restricting user access to transcoding.

[Luke 42080]

4 hours ago, JuJuJurassic said:

Hi Netbug,

I had this exact problem, with an LG client. I spent ages looking at it, have a look at my posts, and then for some reason, it just started working again. I never did get to the bottom of it. But do read my posts it will hopefully save you some time. Here's the url;

 

 

 

The lg tvs have cheap network chips and can’t handle high bitrate bitrates.

[JuJuJurassic 49]

20 hours ago, Luke said:

The lg tvs have cheap network chips and can’t handle high bitrate bitrates.

I have a 4k Firestick that buffers on large 4K files, but the LG TV handles it perfectly. The TV is wired ethernet, and the Firestick is Wi-fi, but with a Netgear Orbi, so it's got plenty of bandwidth.

If it was a problem with the chips then it would be constant, it's not. It appears to come and go. Almost like a temporary folder filled or the client ran out of memory, but it's not the chips as it's not consistent. I have the LG client failing to move after a single button had been pressed. There was no network traffic used then, it was on the opening screen, going from the TV library to the Movies, it took 20 seconds.

 

[Netbug 26]

For the past couple of days, I've been playing content through the Android app on my Samsung S22 cast to a Chromecast Ultra connected to the LG TV. There has been no lag. So it does seem to be the LG app that's the problem.

It's odd because the files are no different than I have played in the past; not 4K or anything. Some 1080p, but mostly 720.

Oh well. Appreciate the help. If i can provide anything else to further troubleshoot, please let me know. It's a bit of a pain controlling form the phone instead of the remote, so it would be nice to get it corrected... especially given the cost of the LG G1.