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

[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..