Jump to content

High bitrate videos stop every few seconds (direct play)


redtr
Go to solution Solved by rbjtech,

Recommended Posts

Hello, I have been evaluating Emby in the last couple of days and really like it. Unfortunately there has been one issue that prevents me to commit to it.

High bitrate videos stop every few seconds (probably buffering, though there is no loading indication) and by high bitrate I mean 70+mbps. Works fine with other videos. I am doing my own rips of Blurays with no compression and I am not interested in transcoding as I want to enjoy my movies at the best possible quality.

My setup is server + client on Nvidia Shield Pro (2019). The Shield has a wired gigabit connection to my router and the hard drive where my videos are is connected to the router (USB3.0). My first thought was there is not enough bandwidth, but I can play the same files just fine with Kodi and Plex (same setup - server + client on the Shield). So the issue is probably in Emby, which is a shame because I prefer it and would be happy to pay for it. I tried with the latest official versions of the server and the client, and also the latest beta versions of both.

I sent logs via the app with reproduction of the issue:

Movie played: Gemini Man

Name of the user on the local server: redzhep

Time I sent the logs: around 02:20 PM ET

Server version: 4.6.0.34 beta (reproducible with 4.5.4.0 as well)

Client version: 2.0.00g (reproducible with 1.8.55g as well)

Let me know if there is some additional information that I can provide.

Edited by redtr
Link to comment
Share on other sites

rbjtech

Is the server transcoding ?

If you hold down the centre button on the Shield for a second or two and release it, it will bring up information on what it is doing.  Do the same to remove the info.

The Shield will pretty much direct play anything you throw at it - so i would be surprised if it was.

Emby can play 120Mbit+ files without issue on the shield - so something is not quiet right here.

Edited by rbjtech
Link to comment
Share on other sites

8 hours ago, redtr said:

the hard drive where my videos are is connected to the router (USB3.0).

That's my first suspect for an I/O bottleneck but hard to be sure.  For kicks, you could try using a wireless connection from the Shield.

Link to comment
Share on other sites

8 hours ago, rbjtech said:

Is the server transcoding ?

Nope, this is direct play, as mentioned in the title.

 

7 hours ago, Luke said:

HI there, please attach the emby server log as well. thanks.

I don't have debug log from the previous reproduction, but I reproduced it again and I'm attaching the new server logs here. Same movie Gemini Man - I let it run for a minute or two, it stops every 15-20 seconds.

 

4 hours ago, ebr said:

That's my first suspect for an I/O bottleneck but hard to be sure.  For kicks, you could try using a wireless connection from the Shield.

I doubt it's an I/O issue - Kodi, Plex and VLC can play the same file, from the same place with no issues. Using a wireless connection introduces some more buffering on all apps, while the wired connection is completely smooth with the aforementioned apps.

embyserver.txt

Link to comment
Share on other sites

rbjtech

So your HDD is connected to the Router you say (via USB) and then mounted as a SMB file share ?  You then have mapped the Shield to point to this SMB file share ?

If yes, that 'should' work fine but two options to try (to narrow this down, I'm not suggesting it stays like this) - a) connect the USB HDD directly to the shield pro - and mount the storage that way. b) Mount the SMB storage directly on Shield and play the file 'Direct' using 'File' mode in Emby.  (there are some details in wiki on how to do this).

If either of these methods then work ok - then the issues are something to do with the 'streaming' aspect of emby.

If you have a PC or other fileshare device - then it would also be good to use that as an alternative file share just to try and also do a file copy from the router SMB share vs this new share - and see what transfer rates you get. 

 

 

 

Link to comment
Share on other sites

1 hour ago, rbjtech said:

So your HDD is connected to the Router you say (via USB) and then mounted as a SMB file share ?  You then have mapped the Shield to point to this SMB file share ?

Yes, HDD is connected to the router and I'm accessing it as an SMB share using the "Mount network storage" function in the Shield's Storage settings.

1 hour ago, rbjtech said:

a) connect the USB HDD directly to the shield pro - and mount the storage that way

That's not exactly easy to do as my HDD is formatted as ext4 (that works best with the router) and the Shield does not support that. But I have another USB3 drive I can copy a movie to and try that way.

1 hour ago, rbjtech said:

b) Mount the SMB storage directly on Shield and play the file 'Direct' using 'File' mode in Emby.  (there are some details in wiki on how to do this).

I can't seem to find any details on 'Direct' play in 'File' mode, can you point me to the correct article please?

1 hour ago, rbjtech said:

If you have a PC or other fileshare device - then it would also be good to use that as an alternative file share just to try and also do a file copy from the router SMB share vs this new share - and see what transfer rates you get.

I have a Windows laptop I can use to create another SMB share an try that.

 

I will try those suggestion and report back. Thanks!

Edited by redtr
Link to comment
Share on other sites

  • Solution
rbjtech
8 minutes ago, redtr said:

I can't seem to find any details on 'Direct' play in 'File' mode, can you point me to the correct article please?

https://support.emby.media/support/solutions/articles/44002058112-shield-tv-direct-file-access

To add to this wiki (which should be in there actually..) it's important that the server is uppercase in the optional emby library path.

ie if your normal unc path is \\server\myshare - the optional library path should be \\SERVER\myshare - as that is how the SHIELD mounts them - lowercase will not work.

@cayars - Could we update the wiki to state this please ?

Ah apologies - you have in the other associated doc - https://support.emby.media/support/solutions/articles/44001159320-optional-network-paths

:)

 

 

Edited by rbjtech
  • Like 2
Link to comment
Share on other sites

Hey, that seem to have helped! Thanks!

I guess this narrows down the issue to the streaming, is there any way I can help to investigate that further? I found this older thread that sounds like same thing and if so, I guess this is a recurring issue.

 

For future reference if anyone else encounters this issue:

1. I have added an optional UNC path to my library like so

path.png.510c343dc9030788e137f20a26d7bc35.png

path2.png.43c23270bfc139297d7f788906b54c45.png

2. Enabled "Pass Direct Path" in the Emby client's Playback settings

3. When the video is playing the Stats box shows "Stream type: File"

 

  • Like 2
Link to comment
Share on other sites

So we clearly have some sort of I/O inefficiency somewhere with this kind of setup...

Link to comment
Share on other sites

rbjtech
2 hours ago, redtr said:

I guess this narrows down the issue to the streaming, is there any way I can help to investigate that further? I found this older thread that sounds like same thing and if so, I guess this is a recurring issue.

Great - glad that method works out for you.  VLC, Kodi and I believe Plex uses a direct file method.

Normally, Emby uses an intermediate HTTP webserver that encapsulates the source file into web based packets -  which are then sent to the client.   

With high bitrate 4K remux files - the overhead of doing this may stall the transfer.    A while back the Windows version of emby server had a similar issue - anything over approx 50Mbit stalled - and the emby team added the direct file method which bypassed the intermediate process - thus issue fixed.  They then also fixed the Windows http encapsulation so it no longer had these issues - so for Windows users, either method can stream 100Mbit+ 4K remux without any issues - but as @ebr has said, it sound like the process on the Shield needs some efficiencies/tuning.

I don't have a 2nd shield to test,  but it would be interesting to see if the http streaming method to another shield works ok - ie it is the server + playback that is proving the bottleneck.  

 

Link to comment
Share on other sites

You are most likely right.

I don't have a second Shield either, but I do have the means to spin up a seconds Emby server (Windows) and a second Android TV device (an older Sony TV) - here are my findings:

- Playing on the Shield from the Windows server (Stream type: HTTP) - no issues, everything seems smooth

- Playing on another Android TV device from the Shield server (Stream type: HTTP) - it does not freeze, the video doesn't stop every 15-20 seconds. There is some micro stutter but that's probably a networking issue since the TV is in another room and connected wirelessly (lower bitrate movies are fine).

Let me know if there is any other test I can do to help examine this problem further.

 

By the way, it seems that enabling "Pass Direct Path" client side is enough to trigger "file mode", even without providing the optional UNC path for the library. I haven't updated any of my other libraries (so they have empty "Shared network folder") but playing videos from them results in "Stream type: File".

  • Like 1
Link to comment
Share on other sites

rbjtech
52 minutes ago, redtr said:

By the way, it seems that enabling "Pass Direct Path" client side is enough to trigger "file mode", even without providing the optional UNC path for the library. I haven't updated any of my other libraries (so they have empty "Shared network folder") but playing videos from them results in "Stream type: File".

Interesting - perhaps emby is automatically substituting this - @ebr ?

Link to comment
Share on other sites

54 minutes ago, redtr said:

By the way, it seems that enabling "Pass Direct Path" client side is enough to trigger "file mode", even without providing the optional UNC path for the library. I haven't updated any of my other libraries (so they have empty "Shared network folder") but playing videos from them results in "Stream type: File".

Did you add UNC path for the locations?

Link to comment
Share on other sites

1 hour ago, cayars said:

Did you add UNC path for the locations?

If you mean the optional "Shared network folder" path for the library folder, I have added it to one (out of three) of my libraries, and have since removed it because it works without it. I can play videos from all of my libraries and it results in "Stream type: File". All of my libraries are in the same SMB location though, so if the server is caching that location, that might explain it.

Link to comment
Share on other sites

No I meant if you setup the library with:
F:\Movies then you will need the optional UNC path filled out to play back directly via file mode.

However if you originally setup the library with"
\\EMBYSERVER\F\Movies or a UNC path then there is no need to fill in the optional UNC path.

Link to comment
Share on other sites

My network drive is mounted using the Shield's "Mount network storage" menu to /storage/ROUTER/ so my library paths look like /storage/ROUTER/root/Movies.

Link to comment
Share on other sites

4 hours ago, redtr said:

Ah, so that's expected? This article led me to believe I need both the mounted storage and the optional network path specified.

 

You would if the server wasn't also running on the Shield.

  • Like 1
Link to comment
Share on other sites

Yes, the workaround using file mode works.

It seems there are some alleged performance issues with the Android server mentioned in this thread. Is this something you guys are planning on examining further and can I help with anything?

Link to comment
Share on other sites

4 hours ago, redtr said:

It seems there are some alleged performance issues with the Android server mentioned in this thread. Is this something you guys are planning on examining further and can I help with anything?

It's more the limitation of the hardware itself than the software.

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...