markkundinger 2 Posted December 5, 2019 Share Posted December 5, 2019 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 More sharing options...
Luke 36879 Posted December 5, 2019 Share Posted December 5, 2019 HI there, are you using a reverse proxy? Link to comment Share on other sites More sharing options...
markkundinger 2 Posted December 5, 2019 Author Share Posted December 5, 2019 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 More sharing options...
Luke 36879 Posted December 5, 2019 Share Posted December 5, 2019 Let's look at an example. Please attach the information requested in how to report a media playback issue. thanks. Link to comment Share on other sites More sharing options...
markkundinger 2 Posted December 5, 2019 Author Share Posted December 5, 2019 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 Link to comment Share on other sites More sharing options...
Luke 36879 Posted December 7, 2019 Share Posted December 7, 2019 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 More sharing options...
SeRu 0 Posted December 12, 2019 Share Posted December 12, 2019 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 More sharing options...
markkundinger 2 Posted December 14, 2019 Author Share Posted December 14, 2019 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 More sharing options...
markkundinger 2 Posted December 14, 2019 Author Share Posted December 14, 2019 (edited) <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 December 14, 2019 by markkundinger Link to comment Share on other sites More sharing options...
ebr 14855 Posted December 14, 2019 Share Posted December 14, 2019 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 More sharing options...
SeRu 0 Posted December 14, 2019 Share Posted December 14, 2019 (edited) 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 December 14, 2019 by SeRu Link to comment Share on other sites More sharing options...
markkundinger 2 Posted December 16, 2019 Author Share Posted December 16, 2019 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 More sharing options...
Luke 36879 Posted December 16, 2019 Share Posted December 16, 2019 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 More sharing options...
markkundinger 2 Posted December 17, 2019 Author Share Posted December 17, 2019 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. Link to comment Share on other sites More sharing options...
markkundinger 2 Posted December 24, 2019 Author Share Posted December 24, 2019 @@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 More sharing options...
Luke 36879 Posted January 2, 2020 Share Posted January 2, 2020 Hi, are you still running into this? Link to comment Share on other sites More sharing options...
markkundinger 2 Posted January 4, 2020 Author Share Posted January 4, 2020 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 More sharing options...
markkundinger 2 Posted February 3, 2020 Author Share Posted February 3, 2020 @@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 More sharing options...
Luke 36879 Posted February 3, 2020 Share Posted February 3, 2020 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 More sharing options...
Solution markkundinger 2 Posted February 6, 2020 Author Solution Share Posted February 6, 2020 (edited) 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 February 6, 2020 by markkundinger 1 Link to comment Share on other sites More sharing options...
Luke 36879 Posted February 6, 2020 Share Posted February 6, 2020 Hi that's great, thanks for the feedback ! Link to comment Share on other sites More sharing options...
Zaphod414 4 Posted December 31, 2021 Share Posted December 31, 2021 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 More sharing options...
Luke 36879 Posted December 31, 2021 Share Posted December 31, 2021 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 More sharing options...
Zaphod414 4 Posted January 1, 2022 Share Posted January 1, 2022 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. 1 Link to comment Share on other sites More sharing options...
ebr 14855 Posted January 2, 2022 Share Posted January 2, 2022 Hi. Is there any caching like CloudFlare involved? Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now