![]() |
Implement true 'Direct Play' when using 'External Player' to reduce network routing - Printable Version +- Jellyfin Forum (https://forum.jellyfin.org) +-- Forum: Support (https://forum.jellyfin.org/f-support) +--- Forum: Troubleshooting (https://forum.jellyfin.org/f-troubleshooting) +--- Thread: Implement true 'Direct Play' when using 'External Player' to reduce network routing (/t-implement-true-direct-play-when-using-external-player-to-reduce-network-routing) |
RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - zaudio - 2023-10-17 (2023-10-17, 06:45 PM)000 Wrote: yes cifs is v1 but i dont see the requirement on androidnot quite... the jellyfin androidtv client external player (which is actually on my Zidoo Z9x) does NOT get to open smb ![]() ![]() I would prefer the andoid tv client's external player WOULD open smb ![]() 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. RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - Deleted User - 2023-10-17 let me see if i got this, finally usb drive -> shield -cifs> synology -> docker -> jellyfin server -> jellyfin androidtv on zidoo -> zidoo external player ? RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - zaudio - 2023-10-17 (2023-10-17, 07:43 PM)000 Wrote: let me see if i got this, finally Yes, exactly. RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - Deleted User - 2023-10-17 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 RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - zaudio - 2023-10-17 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. RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - Deleted User - 2023-10-17 inside the docker container : mount -t cifs //shield/mount /path/in/docker --verbose -o vers=2.1,user=* Quote:vers=- https://manpages.debian.org/testing/cifs-utils/mount.cifs.8.en.html RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - zaudio - 2023-10-18 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 RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - zaudio - 2023-10-18 (2023-10-18, 02:01 AM)zaudio Wrote: 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.. RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - TheDreadPirate - 2023-10-18 (2023-10-18, 08:36 PM)zaudio Wrote: 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. RE: Implement true 'Direct Play' when using 'External Player' to reduce network routing - Deleted User - 2023-10-18 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 |