Playback Issues - Buffer Stops and Low FPS

[saltedhash 4]

Hi all,

 

I've been an Emby user for about a year now and have learned lots along the way. I'm hoping to get more involved in the community to help out others that may have ran into the same issues I have. In this instance, I'm hoping for some help.

 

System Specs:

Emby Version 4.0.2.0

Windows Server 2016

Xeon L5520 2.27GHz x2

14GB of RAM

Emby server running on a 15K SCSI drive

Storage content on external hard drives via USB 3.0 running DrivePool in a single pool

~15Mbps upload speeds

 

 

Last night I had two external users streaming from my server at the same time (calling them User1 and User2 based on transcode logs attached).

 

User1- Watched movie on a Roku Stick. He said the movie stopped and buffered over 8 times. He was direct streaming the file based on the dashboard and the bitrate was below my maximum set.

 

User2- Watched a movie on Emby Chrome. Movie started getting choppy and he stopped playing about half way through based on performance. Looking at the log, FPS dipped below 10 at the end (my understanding is it shouldn't go below 24 FPS for smooth playback?).

 

I have transcode throttling enabled, but I happened to be home during these streams so I was keeping an eye on server performance. My CPU never went above 20% even if both streams were at a stage that the throttle was turned off. RAM and Drive had plenty of juice left as well.

 

The transcode logs are attached, but according to the directions the FULL server log should be uploaded as well. I'm a bit hesitant to do this as it will disclose my user's IP addresses, my domain, internal configs, etc. If the snippet of logs where these two users came into play would suffice, I can upload that.

 

Thank you in advance for your help!

 

 

User1-transcode-rokustick.txt

User2-transcode-embychrome.txt

[Luke 37254]

Hi, at least in the chrome session it looks like you're just not getting fast enough transcoding for this to be playable, but we'll see what @@softworkz thinks. Thanks.

[saltedhash 4]

Hi Luke,

 

Thanks for the response. The playback switched between throttled/non-throttled constantly, so it was staying around 2 minutes ahead of playback the entire time. Is this what you're referring to? Is it possible for it to not transcode fast enough even if it is well beyond the playback marker? It kept up in that respect from what I was seeing.

[softworkz 3349]

Don't worry there's no problem with your server's performance.

 

1. Each time when no throttling is active the processing speed is at about 3.7x like it can be seen at the start of the output log
   .
2. The stats report lines that can be seen are showing values that are averaged over time since transcoding start.
   They are calculated regardless of any throttling periods, which means that starting with the first throttle activation, they can be no longer trusted!
   .
3. To illustrate this, imagine the following example
   • You start playback of a 1h video
   • After 5 min you pause playback
   • The server will continue to transcode up to position 7.5 min
   • After 30min you resume playback
   • Throttlng will be deactivated and transcoding continues
     => Now, ffmpeg thinks that it had taken 35 min to transcode 7.5 min
     => It will display a speed of 0.21x
4. The report line interval is constant, though. Based on the number of those lines between written segments I could conclude the statement #1...

[softworkz 3349]

For the actual problem, there's two possible causes:

• Server-to-client bandwidth is not sufficient
• Client's regular reporting of its playback position does not work for some reason

The latter case is something that we're investigating currently.

[saltedhash 4]

That definitely makes sense for User2 and something I wasn't aware of. This makes me feel better. For User1, the buffering was most likely a bandwidth restriction then. I've had 3+ people stream at the same time with my bandwidth limitations (I also have a 10mbps limit per user) with no issues, but probably because the shows were a lower bitrate at other times. 

 

Thank you for clearing this up and being so prompt!

[softworkz 3349]

That definitely makes sense for User2 and something I wasn't aware of. This makes me feel better. For User1, the buffering was most likely a bandwidth restriction then. I've had 3+ people stream at the same time with my bandwidth limitations (I also have a 10mbps limit per user) with no issues, but probably because the shows were a lower bitrate at other times. 

 

Thank you for clearing this up and being so prompt!

 

Many of the Emby clients are performing tests to determine the available network bandwidth.

Those tests are performed regularly. They can't be performed right before playback because that would impose a significant playback delay.

 

No imagine 2 clients which have both performed their bandwidth tests in the background.

Both could have detected your 15 Mbps bandwidth separately. But when both clients are starting playback simultaneously, each will assume 15 Mbps while in reality they need to share that bandwidth (=> just 7.5 per client).

 

 

To deal with that situation, you can set server-side bandwidth limitations. E.g. to support three simultaneous clients, you would need to divide your bandwidth by 3 and subtract some tolerance, so you might configure 4 Mbps as a server bandwidth limit.