Jump to content

Direct play takes forever to start, transcode is ok


markkundinger
Go to solution Solved by markkundinger,

Recommended Posts

markkundinger

Hello!

 

Lately, I've noticed that movies that can Direct Play take forever to start playing, while movies that transcode can start playing quite quickly.

 

An example is a 30 minutes TV show might take 30 seconds before it starts playing, on my local network.  A movie takes even longer before it starts playing.

 

Once it starts streaming it's ok, although if I fast forward or rewind I have the big wait again.

 

I'm using server 4.3.0.30 on ubuntu.

I've noticed it on the following clients

 Apple TV 4th gen (not 4k) on local network

 Fire Stick 4k on local network

 Samsung TV on local network

 Web interface remotely

 

If it's a setting I have wrong... I honestly can't figure out what it is.  

 

I'm attaching a embyserver log, the problem was on the most recent show I attempted to watch remotely.  if I watch the DVD rip version, the container's not supported and it transcodes and it's ok.  If I view a h.264 mp4 version of it, it could direct play, and I get the long pause before start.

Link to comment
Share on other sites

markkundinger

noper.  internally it's just the ip address

and externally, it's just my router forwarding the port over to emby.

 

the server is using virtual machine's, but emby's is basically a vanilla ubuntu server with not much else installed.

Link to comment
Share on other sites

markkundinger

oh sorry i thought i had posted my emby server log... but I guess I didn't.  here it is.  again, the last playback attempt is one with the long directly play lag.

 

Also attaching screenshot of the 'waiting circle" image I get for 30 seconds plus before play.  It doesn't look like much, just the Fresh Prince of Bel Air backdrop.

 

Oh, and I forgot, but when I look at windows task manager during the lag, I don't see any network activity.  So whatever the delay is, the server isn't transmitting me the entire movie before starting or anything.

embyserverlog.txt

post-384183-0-78812400-1575571676_thumb.png

Link to comment
Share on other sites

I thought you said you were inside your local network? Judging from the browser address bar I'm not so sure. Can you try accessing the server by your lan ip instead?

Link to comment
Share on other sites

Exact same Problem here. My Config: Cliqz (Firefox), Safari or Chrome on MacOS. Emby Server 4.3.0.30 on QNAP 431P NAS. Both, Mac and NAS, are connected with 2x1GBit and GBit Switch. Processor of NAS is too slow for transcoding at all. If I try, ffmpeg Process runs 85-95% CPU...

Movies stuttering, I think, since 2 or 3 Releases of Emby Server. Most of the time I watch my Movies on my Android TV-Box with the Emby App, or with KODI (EmbyCon). Both does`nt have such behavior.

Logs are attached.

embyserver.txt

ffmpeg-transcode-b66b03f4-873b-4f5d-8f38-31f18b8a338f_1.txt

Link to comment
Share on other sites

markkundinger

SeRu, i think our problems are the opposite.  You're saying that directplay is ok, and transcoding is slow?  that's common.  And your QNAP has ARM processors so I don't know if there's hardware acceleration available?

 

web browsers are probably only going to be able to handle h.264 video, so if the movie is some other format video, it would transcode.  And most audio formats other than AAC won't work either, so would need to be direct streamed.

 

 

I thought you said you were inside your local network? Judging from the browser address bar I'm not so sure. Can you try accessing the server by your lan ip instead?

okay luke, sorry to trick you.  most of my testing had been local, but I did a movie or two over the remote access from work.

 

I retested on a simple scenario. 

web browser client

both on lan, client and server literally a desk apart, connected by gigabit ethernet.

 

Second to last movie is The Usual Suspects (MPEG-2), which transcodes

From when I click "play" to when I see the logo playing onscreen is 4 seconds

 

Last movie is The Usual Suspects (H.264 AAC), which can direct play

from when I click play to when I see the logo is 30 seconds.

 

I looked at the server using "atop" and didn't see any special activity on CPU or disk during this time.  I saw one or two spurts of network activity separated by some lags.  So I dunno where the delay came from before it started playing.

 

i'm attaching the embyserver and the transcode log from the tcode that worked fine.

embylog2.zip

Link to comment
Share on other sites

markkundinger

<posted twice on accident>

 

... but I forgot to mention I tried emby theater for windows and did not have the delays when started to directplay the movies.  

 

the delays were on web browser (and also samsung TV and fire stick 4k)

Edited by markkundinger
Link to comment
Share on other sites

Luke can shed more light but, to me, it almost looks like the web player is pre-buffering (possibly the entire movie).  I could see four 6 second long requests for segments of the movie being requested and delivered before playback actually started.

Link to comment
Share on other sites

SeRu, i think our problems are the opposite.  You're saying that directplay is ok, and transcoding is slow?  that's common.  And your QNAP has ARM processors so I don't know if there's hardware acceleration available?

 

web browsers are probably only going to be able to handle h.264 video, so if the movie is some other format video, it would transcode.  And most audio formats other than AAC won't work either, so would need to be direct streamed.

 

 

okay luke, sorry to trick you.  most of my testing had been local, but I did a movie or two over the remote access from work.

 

I retested on a simple scenario. 

web browser client

both on lan, client and server literally a desk apart, connected by gigabit ethernet.

 

Second to last movie is The Usual Suspects (MPEG-2), which transcodes

From when I click "play" to when I see the logo playing onscreen is 4 seconds

 

Last movie is The Usual Suspects (H.264 AAC), which can direct play

from when I click play to when I see the logo is 30 seconds.

 

I looked at the server using "atop" and didn't see any special activity on CPU or disk during this time.  I saw one or two spurts of network activity separated by some lags.  So I dunno where the delay came from before it started playing.

 

i'm attaching the embyserver and the transcode log from the tcode that worked fine.

Yes, transcoding is very slow, compared to direct play. Poor 13 FPS, compared to original framerate of 24-30 FPS with direct play. Even h.265.. The QNAP NAS does`nt support video acceleration. That`s why transcoding should be avoid.

On the other side, with older versions of Emby none of my Players, including Webbrowser, had problems to play any of my movies. The stuttering and the Start-lag appears just since the last few updates.

Could ffmpeg be the Problem? Its separately installed (the newest Version) on the NAS.. I deactivated it, but Emby does`nt stop stuttering.

Edited by SeRu
Link to comment
Share on other sites

markkundinger

SeRu, again, opposite problem as mine, but it sounds like you need your clients to direct play instead of transcode.   In your client, you can look for a "stats for nerds" option that might show why it's transcoding.  failing, that, go to the web interface for your server, and the web dashboard can show the reason for a transcode sometimes.

 

The usual reasons for a transcode:

* video format not supported (h.265, mpeg 2, etc)

container not supported (apple products)

* audio format not supported

* subtitles not supported.

* client bandwidth not set high enough

* server bandwidth isn't high enough

 

 

Luke can shed more light but, to me, it almost looks like the web player is pre-buffering (possibly the entire movie).  I could see four 6 second long requests for segments of the movie being requested and delivered before playback actually started.

 

@@Luke any idea there?  

Link to comment
Share on other sites

Try using the chrome debugger to monitor the network tab while seeking through the video. Are there Range request and response headers?

Link to comment
Share on other sites

markkundinger

sorry, is there an ELI5 for how to use the chrome debugger to tell you something useful?

 

Do I hit ctrl-shift-C to bring up that console?  then what?

 

I tried looking at 'network' when starting or skipping through video.  I didn't see range requests but I may not have been looking for the right thing.

 

what I did see what that after I started playing (or skippoing) is that there was a new stream.mp4 entry, but that it took... about 15 seconds in this case, until the "size" actually started showing any data.  and then the MB started incrementing while the video was playing.

 

5df931e1b6854_20191217_114801.png

Link to comment
Share on other sites

markkundinger

@@Luke becuase I don't think I know how to get the debugger info you're looking for, but I can try with a more dummy-friendly instructions.  thanks!

Link to comment
Share on other sites

  • 2 weeks later...
markkundinger

Hi, are you still running into this?

 

Yup!

 

All I have to add is that the problem happens on my main server, where emby is in it's own ubuntu VM.  

I tried it on a backup laptop server, using windows, and it doesn't have the problem where direct play takes a long time to start.

 

I haven't had time to set up a different Linux system to see if there's some configuration problem on my part.

 

Also, I don't know how to do... whatever.. with Chrome to see range requests or response headers.  But I probably could with a walkthrough for babies.

 

If either or both of these things are helpful for you let me know!

Link to comment
Share on other sites

  • 5 weeks later...
markkundinger

@@Luke, I wanted to check back in on this.

 

It seems like it's sorta a system issue on my end, in that direct play being slow is limited to Emby on Ubuntu 18.04 and on an esxi virtual machine.

 

what I can't figure out is what is happening that's slowing down the playing.  Is there a client log that I can look at or something?  that would probably help determining where the wait is when trying to direct play.  Any suggestions?

 

Here are my test results.  "System 1" is my "production" system with an AMD 10 and runs esxi 6.7u2.  System 2 is a Dual Xeon running esxi 6.7u3b.  ubuntu is always ubuntu 18.04.3.

 

System 1 -> esxi Ubuntu -> slow

System 2 -> esxi ubuntu -> slow

System 2 -> bare metal ubuntu -> fast

System 2 -> esxi Windows -> fast

System 2 -> bare Windows -> fast

Link to comment
Share on other sites

If you can reproduce it in the browser then the browser debug console is really your best tool. You can look at the network requests, request/response headers, etc.

Link to comment
Share on other sites

  • Solution
markkundinger

TL;DR it looks like it's user error, or at least ubuntu setup error, on how I have my server getting files from my NAS.

 

Here's what I know from trying to troubleshoot with firefox's debugger.

 

when starting to directly play the show, there are two back to back requests for mp4's, each of which takes 6 seconds to run:

 

 

Now in my VM setup, I have one ubuntu VM running emby, and another Debian VM as a NAS running Openmediavault, which has all the movie files.

 

So I thought "what the hell" and copied the files to the local drive of the emby VM.  And then the movies started up quickly!

 

Tentative Conclusion: So it must have something to do with the way I have my emby ubuntu mounting the drives on the NAS.

 

EDIT: a few minutes later, it was messed up options in my ubuntu's fstab mounting the nfs drive.

 

before I had something like this

e-NAS:/export/media   /srv/media      nfs     auto    0     0

and then I followed a walkthrough more literally and put in this:

192.168.200.201:/export/media   /srv/media      nfs     auto,nofail,noatime,nol$    0     0

then it loaded quicker.  was it using IP instead of local ghetto hostname?  Was it one of the NFS mount options I had left out?  Dunno.

Edited by markkundinger
  • Like 1
Link to comment
Share on other sites

  • 1 year later...
Zaphod414

So I'm having the exact same issue now as what is described by OP.  I've just set up a new instance of Emby in a docker container to replace an old instance running in a BSD jail.  When transcoding, playback begins quite quickly - usually within 5 seconds.  At least as fast or faster than it would start on the old setup.  When I try to direct play, though, there is a good 30 second delay before the video starts playing.  The please wait spinner just spins for a good 30 seconds.  The video plays fine once it starts, but if you seek ahead using the position slider you get he same 30 second delay before playback resumes.  I tried the solution that worked for the OP - using the IP address in the NFS mount on the host server instead of the DNS name - but it didn't help.

Log is attached.  It was saved immediately following trying to start a video.  The long running requests appear to be on lines 10826-10827, taking about 26 and 13 seconds respectively. 

Anyone have any ideas?

embyserver_directplay.delay.txt

Link to comment
Share on other sites

3 hours ago, Zaphod414 said:

So I'm having the exact same issue now as what is described by OP.  I've just set up a new instance of Emby in a docker container to replace an old instance running in a BSD jail.  When transcoding, playback begins quite quickly - usually within 5 seconds.  At least as fast or faster than it would start on the old setup.  When I try to direct play, though, there is a good 30 second delay before the video starts playing.  The please wait spinner just spins for a good 30 seconds.  The video plays fine once it starts, but if you seek ahead using the position slider you get he same 30 second delay before playback resumes.  I tried the solution that worked for the OP - using the IP address in the NFS mount on the host server instead of the DNS name - but it didn't help.

Log is attached.  It was saved immediately following trying to start a video.  The long running requests appear to be on lines 10826-10827, taking about 26 and 13 seconds respectively. 

Anyone have any ideas?

embyserver_directplay.delay.txt 3.18 MB · 1 download

 

Long running requests are normal during playback because that's how long you're playing. The delay to start is not though. Are you using a reverse proxy?

Link to comment
Share on other sites

Zaphod414
On 31/12/2021 at 12:17, Luke said:

 

Long running requests are normal during playback because that's how long you're playing. The delay to start is not though. Are you using a reverse proxy?

Yes, I'm using an Nginx reverse proxy.  It's the same reverse proxy I've been using for years without issue with the previous Emby instance.  I'm using the same instance of the reverse proxy, and in fact the very same proxy entry as I have been using previously without seeing this delay.

I also have some additional results to share, as I've been working this issue ever since first posting.  I have managed to get rid of the delay locally by setting the shared folder path in the library options (see screenshot).  This only seems to have bypassed whatever the problem is, though, as it only fixed the problem locally.  Playing through a remote connection still yields a huge delay when direct playing.  Now here's the really weird part.  At first, I thought this was affecting all files in my library equally, but of course it's not going to be that easy.  The delay is actually only affecting some files and not others.  Some files take a good 30 seconds to start, and give a similar delay when seeking around in the file.  Other files, though, start without delay in startup and seeking.  This is consistent, in that the same file will either start normally or start with delay each time it is opened - so affected files are always affected and unaffected files always work cleanly.  That's where the consistency ends, though, as It does not seem to matter what video or audio codecs are used in the files.  I have both working and affected examples of each.  So far I have not found any consistent connections between the files that work and the files that give the delay. 

My theory so far is that the issue has to do with Emby piping the video stream out through an HTTP/HTTPS stream.  That's the only part that would have changed when I specified the share paths for the libraries.  Direct playing locally now allows the Emby client to access the file directly though the share rather than going through the HTTP stream.  Note that in my old Emby instance, I did not even specify the share paths, and so everything I ever played went through the HTTP stream whether local or remote.  Since it always worked fine like that, that's how I left it configured. 

Emby library shared folder path.png

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...