Incredibly Laggy/Jumpy on Everything Except Local Machine

[Netbug 26]

Version 3.0.5800.3

 

I cannot figure out what's going on here. My first thought is network problems, but the network is pretty solid and throughput is totally fine (about 200mbps locally). My internet connection is also fine (300mbps download, 20mbps upload).

 

I've restricted playback to 5mbps, but I can still only get a few seconds of playback at a time before it pauses and starts.

 

My family and friends when connecting remotely, are getting the same problem. This is on all clients we have tested (browser, MBT, iPhone, Windows Phone, Android).

 

The only playback I can get to work properly is running on the computer that's hosting the Emby server itself.

 

Media is housed on a second machine (unRAID). Emby is running on a Windows 8.1 machine.

 

Where can I start looking for problems and troubleshooting this? I THINK it's a transcoding issue, but I don't know enough about it to troubleshoot/correct.

 

Logs: http://1drv.ms/1R5u4a9

Edited January 2, 2016 by Netbug

[Luke 42080]

Possibly related to

 

http://emby.media/community/index.php?/blog/1/entry-272-emby-website-status/

[Netbug 26]

It's still happening right now even with a direct connection to the server on the local network (192 IP). And has been occurring for a few weeks.

 

Still possibly related?

[Luke 42080]

Then isolate it once, capture one set of logs (as opposed to a whole bunch), and then discuss what happened at various points in time. Thanks.

[Netbug 26]

Then isolate it once, capture one set of logs (as opposed to a whole bunch), and then discuss what happened at various points in time. Thanks.

 

It's generating a constant stream of transcoding logs from just one person trying to play back. Is that normal? All those transcoding logs in the link are from within the last 30 minutes.

[Netbug 26]

I have replaced the log files with the three that were generated on the last playback attempt a moment ago.

 

As to discussing what happens... the stream just pauses every few seconds. The longest it will play without pausing is less than 60 seconds. This is with all media types.

[Luke 42080]

On an individual basis many of those transcoding logs look fine, although one thing does jump out, which is low transcoding fps. In one log you're only getting 11 fps which is not fast enough to be playable. The other ones I looked at generally fast enough, but just barely.

 

In the new set of logs you're getting 4fps in one, 6fps in another. I see you're on Firefox, which is ok, but I would suggest trying Chrome 47. I'm not trying to tell you what browser to use, but Chrome has more advanced features that allow us to do things that aren't possible in the other browsers, for example, expanded format support which means less transcoding required by the server. You can learn more about that here:

 

http://emby.media/community/index.php?/blog/1/entry-265-emby-server-beta-3057816-released/

 

Also just a point of consideration - you have only a dual core cpu. Judging by this statement, you might want to consider upgrading based on the number of users and devices you have.

My family and friends when connecting remotely, are getting the same problem. This is on all clients we have tested (browser, MBT, iPhone, Windows Phone, Android).

[Netbug 26]

Testing now.

 

Would this also be affecting the other clients (iPhone, Windows Phone)?

[Luke 42080]

Not directly, but it it reduces the load on your server and then someone else tries to play at the same time, then the answer would be yes.

[Netbug 26]

Same result in Chrome.

 

New logs posted after using Chrome in "New Logs 1" folder.

 

Also, what could be causing the framerate to be so abysmal? This was working fine up until a few weeks ago and there were no known changes to the server at that time.

[Luke 42080]

Make sure you've got nothing else on the system consuming the cpu. Try rebooting it.

[Netbug 26]

I just completed a reboot.

 

Screenshot of task manager shared. https://onedrive.live.com/redir?resid=730111136CC6B204!350437&authkey=!ADqQumPwl7nzWSA&v=3&ithint=photo%2cpng

 

The only things chewing through CPU usage are ffmpeg.exe, which i believe is the transcoding (?)

[Netbug 26]

Problem persists. Why would there be two instances for ffmpeg running and why are they consuming so much CPU? :/

[Luke 42080]

I don't know. i think now we're back to here

isolate it once, capture one set of logs (as opposed to a whole bunch), and then discuss what happened at various points in time. Thanks.

kill those ffmpeg processes first though.

[Netbug 26]

Attempting now.

 

Same issue (plays for a few seconds, then stops, then starts).

 

New logs updated (in New Logs 2).

 

I'm not showing ffmpeg.exe running at all in the task manager now, and it didn't generate a new transcoding log.

[Netbug 26]

ffmpeg has started again with 85% (!) CPU usage

[Luke 42080]

You're getting 6-8 fps. If this is caused by multiple ffmpeg instances then that is one thing that can be looked at. but since that didn't happen here, this might just be as fast as your system can transcode that particular content.

 

In chrome I would try going into user settings -> playback, then set the max bitrate to auto. it looks like you set your own bitrate. if you leave it at auto, then it might determine the network is fast enough to direct stream the video. (or might not, it will test and decide).

 

Since you have a 2-core cpu you will definitely want to focus your playback towards direct video stream scenarios.

[chef 3810]

I also have been experiencing this with the beta. The transcode is not fast enough to keep up with the stream. It is jumpy because the stream catches up with the transcode and has to wait for it to create the next set of frames before it can play them.

At least I think...

I am just watching the red and green lines in the manger on my device image.

 

 

Please stop, stay within your topic. This type of post may just cause the original poster to say "yea me too, there must be a problem in Emby". So please investigate first and we'll help you in your own topic. In this issue what I'm seeing so far is server cpu not transcoding fast enough, which causes the client video player to fail and possibly retry which causes another ffmpeg instance to spin up. The second part of that I can fix but I can't make the cpu transcode faster, so that is why i'm giving practical advice about minimizing transcoding.

[Netbug 26]

OK. So it maybe time for a system upgrade. I wasn't expecting that. :/

 

Are there any current recommended specs for performance?

[chef 3810]

I also have been experiencing this with the beta. The transcode is not fast enough to keep up with the stream. It is jumpy because the stream catches up with the transcode and has to wait for it to create the next set of frames before it can play them.

 

At least I think...

 

I am just watching the red and green lines in the manger on my device image.

 

 

Please stop, stay within your topic. This type of post may just cause the original poster to say "yea me too, there must be a problem in Emby". So please investigate first and we'll help you in your own topic. In this issue what I'm seeing so far is server cpu not transcoding fast enough, which causes the client video player to fail and possibly retry which causes another ffmpeg instance to spin up. The second part of that I can fix but I can't make the cpu transcode faster, so that is why i'm giving practical advice about minimizing transcoding.

Okay... Well, that is my experience, however with further investigation, I can report that files with high bitrates are harder to transcode for my computer. Probably the issues are similar, Smaller CPU. Mine is also a duo core.

 

I don't think there is a problem with emby, it is most certainly hardware issues. FFMpeg is always going to pin a CPU really high.

 

Here are some things I have done in order to help transcoding on my low powered machine. This helps with my transcoding in my home network. I don't stream outside of my home.

 

1. Use th 4gig memory patch on the server executable.

 

2. I use a program called "Process Tamer" which I point at emby and ffmpeg.exe to force those processes into "high" or "realtime" processes.

Note: This should be used with caution, pinning process at realtime, isn't always a good idea.

 

3. Utilizing the ffmpeg.exe commandline structure to lower the bitrate in bluray rips which have been ripped with high bitrates.

 

Note: Google will find quite a few different options for command lines which will lower bitrate.

 

In some cases, the lower bitrate might even stop transcoding altogether, depending on codecs.

 

4. Power cycling the computer you are running the server on may help by restarting processes which have been running for long periods of time.

 

For me personally, the files I was attempting to play last night did have high bitrates, ranging above 10000, which was way out of the range for the device I was attempting to send play commands to. Keep in mind that some devices can only handle so much, ir it may request bitrates higher than what your CPU can handle while stream to serval devices. This causes jumpy transcodes for certain.

 

Hope that helps, and is a better suggestion then "I also experience laggy transcodes..."

 

Definitely don't want to cause any chain reactions.

Edited January 2, 2016 by chef

[Netbug 26]

Thanks very much for the information, folks.

 

I'm curious as to what would have changed in the last couple of weeks that has caused such a problem. I hate to have to drop a few hundred dollars to fix and issue which doesn't seem to have been triggered by hardware problems.

 

I'll ask again, does anyone have a recommended hardware spec sheet for the processor and ram? If I'm going to upgrade, I'd like to buy components which are going to be able to process 4-8 streams at a time (predominately to Roku, Web, MBT, and browser).

[Luke 42080]

I think the intel i5 cpu strikes a great balance of price and performance.