Jump to content

Troubleshooting: playback shows only the buffered length, not the total length of media


Recommended Posts

Hi,

 

Before anything else I simply must thank you for your otherwise excellent product: I really like Emby and have been using it for over a year now.  It's pretty, easy to use and the cross-platform apps are superb.  Thank you very much.

 

So, I'm having a problem playing back media.  Whether TV shows, movies etc. doesn't matter.  They play fine: in the browser, using my Apple TV (4th gen) or the iOS app (iPhone).  The catch though is the scrubber doesn't display relative to the length of the media itself, only relative to the amount it has buffered.

 

For example, if 'Dick Spanner: The Case of the Human Cannonball' is 50-ish minutes long then the scrubber will initially show 30-40 seconds total length.  Then more will buffer and the total length will go up.  In order to skip 20 minutes into the media file, I need to wait for 20 minutes worth of media to buffer before the scrubber will let me go that far.

 

Here's a screenshot of an episode of Father Ted to illustrate:

 

post-287746-0-64505900-1519055462_thumb.png

 

It's only about 5 seconds in, but the scrubber makes it look like we're 2/3 of the way through the episode.  

 

It also seems that the media files don't buffer beyond a certain amount- about 5 minutes or so ahead (which makes good sense, saves on bandwidth) but that means I can only skip ahead 5 minutes or so each time.

 

I'd like to be able to start a movie, stop watching it halfway through and then restart it later and scrub to where I left off.  I often access the Emby server remotely and, due to remote access problems, it's not uncommon for movies to cut-off or have to be restarted.  In those cases Emby isn't necessarily aware of where they left off (so no 'Resume' option) and I must scrub to the correct point manually.

 

Now Emby didn't do this until recently, ie in the last week or so, so I can only imagine its either something I've done to our network (quite possible!) or some setting that I've flipped accidentally.  Has anyone seen this?  If so, do you know how I might correct it?  It's trivial... but surprisingly frustrating!

 

I've attached my Emby server logs (there's only one user in the system).

 

-- Set up details:

 

* Emby is running on a Windows Server 2016 box accessing media from an NFS share over a 10/100 CAT7 ethernet connection.

* NFS share is CentOS 7 with a 7 disk (1 spare) RAID6 array.  I changed to this from SAMBA a little while ago due to poor performance.

* Client devices access either over WiFi or remotely through reverse-proxy.

* Emby runs as a standard non-privileged user using the Emby Portable image.  

* All was going fine until about 10 days ago

* Scrubber issue happens on all clients, remote and local.

* I've tested (over WiFi) mounting the NFS share as a drive and dragging-n-dropping a file into VLC, which seems to stream it happily with the scrubber adjusted correctly.

* NFS share has a network throughput of about 10 meg a second, so can download 1GB in about 1-2 mins

 

The biggest change I've made was 2 weeks ago which involved changing from installing as a service to installing the portable edition- running as a service was difficult when trying to mount network shares, it involves granting the service 'logon as user' rights and all sorts.

 

-- My apologies for the complexity and I hope you might be able to recommend what I'm doing wrong any help would be greatly appreciated.  Thank you again for your superb product.

logs.zip

post-287746-0-30386000-1519056009_thumb.png

Edited by ke2083
Link to post
Share on other sites

hi @@ke2083, welcome. This is strange as you don't typically see these kinds of issues on Windows.

 

I can see from the ffmpeg logs that ffmpeg is having trouble reading from the Z: drive. I'm curious to know if the issue isolated to the ffmpeg executable or if the Emby process has similar issues. Is the library indexed in Emby properly aside from the missing media info?

 

There is a reason why we always advise against using mapped network drive letters and instead just give Emby the original \\ network location. The reason is unrelated (I think) but I might as well mention it. Windows will disconnect those drive mappings as the system idles, and this will prevent Emby from being able to access them. This kind of problem won't happen when using the original network location.

 

Please let us know if this helps. Thanks !

Link to post
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...