Implement true 'Direct Play' when using 'External Player' to reduce network routing

[zaudio]

Hi,

When using my NAS that is external to my device running Jellyfin server, I am unable to playback any UHD remuxed movie, and often even regular full HD encodes, without some random stutters, very occasional disconnects.
This is using Jellyfin Android TV Client on my Zidoo Z9x, with 'External Player'. The Jellyfin dashboard confirms that anything I play does 'Direct play'.

The problem is the network routing: see attached diagram


If I play the exact same files from the same external NAS using the built in HT4 media player in the zidoo directly, there are zero issues. I have changed every cable for new Cat6. Routing using Jellyfin or the HT4 player both go via the same switch, and most of the cables... the the issue is not there. The only difference is having to relay via my Jellyfin server device for the mounted share. This of course involves a full duplex transmission to and from that device via ethernet for the duration of the playback. Again see attached diagram.

   

From my perspective you already have part of the idea to solve this. The Library 'network share path'. Please can you update your software to use that when using External player for Direct Play titles... or at least give an option to force Direct Play using the network share path for external player. Both of these would stream the file in my case from my external Nas to my Zidoo Z9x without having to route through the Mounted share on the Jellyfin server device; thus eliminating the additional routing and solving all my playback problems. This would implement a true 'Direct play' option in my opinion and would be a great added feature to Jellyfin.

My shares are all SMB.

It seems a good idea to me to be able to eliminate that additional routing for 'Direct play'; sure there might be something going on in my Jellyfin server's mounted share... I've not been able to find anything, and have tried everything there to reduce any latency (like turning off all SMB logging for one). If Direct play was truly that, I would not have to even deal with that. Nothing I have tried has helped.

Please please please change this. For now I cannot use your app to watch my movies...
Thanks again for all your efforts
Simon

[Deleted User]

i use jellyfin exclusively with android clients, some with kodi with the jf addon and some with the app for android tv

and i only use uhd bd remux and bd remux for movies


but i cant wrap my head around your configuration

when i play from the jellyfin server - it plays via http, my jf server does not even have smb setup

when using 'external player' in the android tv app it just opens another app which is in charge of everything beyond that

for me the only limitations are device limits but i have never had the issues you are describing


what does it do if you use ExoPlayer as the selected player in the android tv app?

what version android tv app?

can you reconfigure your jf to serve via http? (im not even sure how you configured it not to)

[zaudio]

Penultimate version of the android TV app (recent update was very minor so I did not bother).
You are using Kodi, which I believe somehow makes use of that share network path. I do not want to use Kodi on my Zidoo... just too many moving parts. I used to use Kodi on my shield pro.
It's very simply... I have a NAS that runs Jellyfin, and I have a larger more basic NAS with a lot more storage. Playing from that external nas is where the unnecessary routing comes in.
Using anything but 'External player' on my Zidoo Z9x is not an option, as the enture point of my having that device is to use it's most excellent Dolby Vision VS10 player for everything... hence why I no longer use my shield for streaming my mkv files.
In your case your media files are probably all stored on your Jellyfin server, right? Mine are not.
My proposed suggestion would help me, and likely many others also.

[Deleted User]

that clears things up quite a bit

yes i use kodi but also the official jellyfin app, and also custom compiles of forks of the official app
kodi will indeed use smb or addon, i use addon which uses http streaming
i was not recommending kodi, in fact i am building custom versions of the official app to get away from kodi

if you are using external player then the official app is no longer in control
it is doing no more than executing an external app with a command line parameter (basically the same as adb shell am start com.packagename -d path/to/jf/file.mkv)
at that point it would be the external app which opens the location/file and plays it - the jellyfin app is backgrounded)

if exoplayer is not an option then my opinion is contacting the developer of the app that is actually doing the playing
f.e. i would not contact the jellyfin people with help when kodi will not play and i would not contact them if the vlc app would not

as far as jellyfin is concerned my files are 'local' to it but they are actually mounted to the host server running docker, docker just interprets them as local

edit:

my setup is 'file server' -> 'home server' -> 'jellyfin in docker'
file server does serve other functions but they are external to my intranet

[zaudio]

I am contacting Jellyfin as it is the Jellyfin Server/Android TV Client that are the problem here. The server, like you say, only accepts local mounts for its libraries. You cannot specify network share paths directly. I have been told the network share paths you can still add to library configurations are deprecated and were never implemented. I would like the Android TV client when using an external player and Direct Play to actually use those network share paths so my movies are not streamed via the mount points... This would mean my Zidoo player would get a true direct network path to my movie, and not a path to the mount point that the Jellyfin server has - which adds that additional routing that is problematic for me.

[Deleted User]

just for my curiosity - what operating system is your jellyfin server running?

[TheDreadPirate]

I'm not a developer, but my assumption for requiring the jellyfin server to mount the network share has to do with client limitations for communicating with the network share. For example, if you are enforcing a particular SMB protocol and SMB encryption, will the client support it? Does Jellyfin have to bundle SMB support with jellyfin? Now the devs have to maintain that.

By having the operating system handle the network share, the Jellyfin devs no longer have to maintain that within the Jellyfin project's code.

Additionally, SMB is NOT a streaming protocol. And Jellyfin is not simply sending a file to the client. It is streaming the file to the client in chunks using the HLS protocol. With all the flexibility that protocol enables that SMB simply can't.

[zaudio]

"just for my curiosity - what operating system is your jellyfin server running?"

Ubuntu Jellyfin server Docker container prebuilt for the Nas.

"I'm not a developer, but my assumption for requiring the jellyfin server to mount the network share has to do with client limitations for communicating with the network share. For example, if you are enforcing a particular SMB protocol and SMB encryption, will the client support it? Does Jellyfin have to bundle SMB support with jellyfin? Now the devs have to maintain that."

Not so; all Jellyfin has to do is provide a direct network path for the file being played to the external player. It can do this using the existing library config field for Network share path. The external player client has to then know what to do with that path and have all the appropriate permissions to access it... which typically it can have as it's able to access remote shares itself. Mine does for sure, as I can stream the same file directly from the external player. But I want to be able to use the Jellyfin client to manage my library viewing and playing.
I understand why Jellyfin requires a mounted location for files it needs to access itself, ie for transcoding etc... that way all the networking authentication and set up is not contained within Jellyfin. But that need not apply for Directly playing to an external player... that can get a direct path, and not the mounted location.

[mcarlton00]

This feature already exists in the jellyfn-kodi addon.  It's called native mode.  On the Kodi side, we all genuinely hate that it exists, and any issues that come in related to it usually wind up sitting for a while because nobody wants to deal with it.  I would guess that most of the other client devs aren't particularly interested in implementing it.

Ignoring whether they want to, most other clients can't make use of this feature.  As far as I know, the native android tv player cannot, so now it only works with a third party app that we don't control.  And each external app has it's own quirks and requires special code handling them.  Maybe some of them support NFS but not SMB, or vice versa.  Same with android (mobile).  Basically impossible on iOS.  Impossible on Roku.  Impossible in a browser.  So by definition, it's an extremely niche feature that is only functional in a very small minority of cases, and in 95% of use cases where people are already using native mode in the kodi addon it's completely pointless and provides no benefit over normal http streaming.  Basically the only cases where it would be even remotely useful is if the storage is local and the server is remote (on a VPS or something), or when the network is being a potato and can't keep up (what sounds like is happening here).  My guess is that your NAS simply doesn't have the power necessary to process that data being transmitted fast enough, which is unfortunately one of the side effects of using a NAS as a server.

[Deleted User]

so nobody gets the wrong idea, i am not trying to get away from kodi because of the addon - that part is flawless, it is the 'kodi' part that annoys