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

[zaudio]

yes cifs is v1 but i dont see the requirement on android

you have synology hosting docker, in a container there is jellyfin, jellyfin tells the client to open smb/file

then jellyfin androidtv on shield opens external player with smb/host/file

there shouldn't be a requirement for cifs in that chain

what i was thinking is hosting samba inside a container, jellyfin or a new one, and disabling the lower version that synology has

then you wouldn't be stuck on an older version

not quite... the jellyfin androidtv client external player (which is actually on my Zidoo Z9x) does NOT get to open  smb/host/file; it gets a http stream from the JF server, that itself is opening  smb/host/file using CIFS
I would prefer the andoid tv client's external player WOULD open  smb/host/file and thus bypass the stream routing via the jf server... that the whole point of this ticket, and my corresponding feature request

Yes, I get you great suggestion to run samba inside the jf container and create mount points in there to my shield's external drives, thus bypassing the legacy CIFS mount set up on the synology. That might by a solution to the problem if I can get it to work and set up so it persists like I said. Just very unsure how to do that.

[Deleted User]

let me see if i got this, finally

usb drive -> shield -cifs> synology -> docker -> jellyfin server -> jellyfin androidtv on zidoo -> zidoo external player ?

[zaudio]

let me see if i got this, finally

usb drive -> shield -cifs> synology -> docker -> jellyfin server -> jellyfin androidtv on zidoo -> zidoo external player ?

Yes, exactly.

[Deleted User]

got it

forget hosting samba in docker, you might be able to direct mount in docker

but honestly i dont know how to improve that setup other than to simplify it with less hops which i dont think is an option for you

[zaudio]

How would I direct mount in docker?
"but honestly i dont know how to improve that setup other than to simplify it with less hops which i dont think is an option for you"
Precisely my ask of this thread....
I could start moving drives around, buy a load of new hardware to build a new server, all sorts... but I should be able to use this actually simple enough setup. JF should be able to support NAS devices external to the JF server without choking. I think my direct play using network path idea is a solid option.

[Deleted User]

inside the docker container :

mount -t cifs //shield/mount /path/in/docker --verbose -o vers=2.1,user=*

vers=
SMB protocol version. Allowed values are:
1.0 - The classic CIFS/SMBv1 protocol.
2.0 - The SMBv2.002 protocol. This was initially introduced in Windows Vista Service Pack 1, and Windows Server 2008. Note that the initial release version of Windows Vista spoke a slightly different dialect (2.000) that is not supported.
2.1 - The SMBv2.1 protocol that was introduced in Microsoft Windows 7 and Windows Server 2008R2.
3.0 - The SMBv3.0 protocol that was introduced in Microsoft Windows 8 and Windows Server 2012.
3.02 or 3.0.2 - The SMBv3.0.2 protocol that was introduced in Microsoft Windows 8.1 and Windows Server 2012R2.
3.1.1 or 3.11 - The SMBv3.1.1 protocol that was introduced in Microsoft Windows 10 and Windows Server 2016.
3 - The SMBv3.0 protocol version and above.
default - Tries to negotiate the highest SMB2+ version supported by both the client and server.

- https://manpages.debian.org/testing/cifs....8.en.html

[zaudio]

OK, I'm messing with adding the mounts within the container... that gives me options to change the cache to loose and also to set actimeo to a higher than default to reduce chatter. I managed to create the mounts... though had to give my container full privileges as seem unable to get that to work any other way on the Synology so far... I actually created the mounts as version 3.02. I'll how that works out... if it's good, I can add the mounts to the internal container startup apparently. There are also some read buffer settings I could mess with... but one thing at a time

[zaudio]

OK, I'm messing with adding the mounts within the container... that gives me options to change the cache to loose and also to set actimeo to a higher than default to reduce chatter. I managed to create the mounts... though had to give my container full privileges as seem unable to get that to work any other way on the Synology so far... I actually created the mounts as version 3.02. I'll how that works out... if it's good, I can add the mounts to the internal container startup apparently. There are also some read buffer settings I could mess with... but one thing at a time

I think I might have made an improvement with this. I had noticed before that the JF container would slowly consume all the RAM I allocated to it... I was unsure if this was related to the performance problems, as it would just tick along like that anyway. It would use about 3% CPU while playing UHD titles.

I removed the external Synology CIFS mounted shares from my JF container config, and instead in Terminal
installed cifs-utils
created folders for my mounts, and then used
mount -t cifs //[shieldIpAddress]/Media1/NVIDIA_SHIELD /[localMountPath] -o vers=3.02,user=[username],domain=WORKGROUP,ro,cache=none,actimeo=60,rsize=16777216
for each of my shields drives.
I just added my password for access to my shield for that username in a PASSWD environment variable in my container setup; as that gets use if you specify no password on the mount command
I later added these to /etc/fstab so all I then have to do in 'mount -a' after restarting the container... still working on getting that automated in my limited debian container as nothing seems to work for that

With these settings for the mounts, using the SMB3.0.2 protocol I know my shield pro 2019 vs 8.2.2 supports (they added it in 8.2) the JF contained does NOT consume all RAM anymore during playback, and just maintains a base level around 500Mb depending on viewing off poster walls, recent library scans. CPU usage is now 10 to 12% during playback, but that is fine. All in all much more 'stable' than the 'chewing up all RAM' I always had before. I suspect that was the caching from the share, which I do not need for streaming as a read once operation. The actual rsize set for the mount is half that max value I entered above, so 8Mb; this still being 8 x the default of 1MB if you do not specify it.
45 mins of test playback went smooth bar a single slight image freeze (like one frame), but no audio drop out, no real interruption like before. To be clear watching using the Zidoo player without JF never skips a frame...
I'll keep watching my movies through JF now to see just how reliable playback is. I'm thinking it has to be better now the resource consumption is stable, and I have some control of the mounted protocol settings.
Just need to figure out how to do 'mount -a' on startup when my container seems not to have cron, rc.local, services, etc support to do that as you might usually do it.
It would still be good to be able to bypass all this by truly direct playing my media with the external player using JF..

[TheDreadPirate]

mount -t cifs //[shieldIpAddress]/Media1/NVIDIA_SHIELD /[localMountPath] -o vers=3.02,user=[username],domain=WORKGROUP,ro,cache=none,actimeo=60,rsize=16777216

Try changing cache=none to cache=loose.  Another user had a similar issue and they stumbled onto this solution of changing cache to loose.

[Deleted User]

sounds like an improvement, newer version smb, less in the chain, reduced ram usage, more stability

a single frame skip could be just about anything and so very hard to track down


as far as on startup commands, i am not sure how synology does things for docker but docker has ENTRYPOINT and CMD definitions for startup

my jf docker does not have an existing CMD so it would be an additional
ENTRYPOINT is set to run /init, checking that file it calls another

any one of those could get you a way to mount on startup