direct plays take forever to load

[pr3dict 33]

New release and still same issue with live TV....

 

Everything works fine until I try to access live tv. Then all hell breaks lose and everything freezes.

 

 

embyserver broken live tv 2.txt

[Luke 42077]

Does the same thing happen over http? Looks like that's opera mobile, can you try chrome?

[pr3dict 33]

Yeah that last log file was from http:8096 and I am using chrome on windows 10. Version 72.0.3626.109 (Official Build) (64-bit)

[pr3dict 33]

if a device tries to direct play something it takes 30+ seconds to load the file. On the android app + web app the circle just spins. No mention of anything I can see in the server log; attached.

 

 

embyserver nothing plays.txt

[Luke 42077]

Can you provide an android example? thanks.

[Luke 42077]

If you're behind a reverse proxy, make sure it's configured to preserve all http request headers, including range request headers, or something like this may happen.

[pr3dict 33]

If you're behind a reverse proxy, make sure it's configured to preserve all http request headers, including range request headers, or something like this may happen.

 

When I'm on the same network and I connect directly (bypassing the reverse proxy) using the android or iOS app on my iphone/androd it still loads slowly. I remember you bringing up that for some reason it's trying to load the entire file first before playing or something?

[pr3dict 33]

also I noticed you combined the threads I made... The live TV issue is something different entirely. I can't even load the guide or view the channels without my server coming to a halt.

 

I don't think the direct play issue is related. 

[Luke 42077]

 I remember you bringing up that for some reason it's trying to load the entire file first before playing or something?

 

Right that's what it looks like and that's not normal.  You're saying it does eventually play?

[Luke 42077]

The next question would be what is your file system that the media is stored on? I wonder if perhaps when we open the file handles, they are not seekable for whatever reason, thus preventing the server from being able to send back file ranges.

[pr3dict 33]

Right that's what it looks like and that's not normal.  You're saying it does eventually play?

 

It does eventually play... The larger remux's that I have that are 30gb each or so take a significantly longer amount of time. Sometimes 2 minutes+.

 

The next question would be what is your file system that the media is stored on? I wonder if perhaps when we open the file handles, they are not seekable for whatever reason, thus preventing the server from being able to send back file ranges.

 

I'm all about putting on my sherlock holmes hat and finally getting to the bottom of this...

 

I'm using a drive pool. So all of the individual drives 4TB are ext4 but the pool that runs on top of it is MergerFS. The filesystem reports as fuse.mergerfs.

 

https://github.com/trapexit/mergerfs

 

I just remembered that emby is connected to the storage server via nfs. All the clients connect to the storage server via SMB. 

Edited February 17, 2019 by pr3dict

[Luke 42077]

Yea that sounds suspicious to me. It's so many layers of translation involved that support for various features are probably getting lost along the way.

 

As a test, can you try setting up a small test library on the same drive the server is installed on? Assuming that's not also part of that pool.

[pr3dict 33]

hmmmmmm. I don't think I have a samba server on the emby server only a client. I'll work on it and get back to you...

[pr3dict 33]

Real quick. Before I go Frankenstein my setup... Can you explain how the file descriptors work? Is this on the actual video file thats stored on my storage server, or is it where the metadata is stored? Who needs to access it, the emby server or the client?

[Luke 42077]

The emby server needs to access it.