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

[zaudio]

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.

lol I tried that yesterday first, but had the RAM runaway still, and more viewing instability... but somewhat better than with the default shares the synology presented, which showed as cache=strict in the mounts list.
I just do not think I need read caching... as its read once streaming. I think the rsize still takes effect in the chunk read from the stream on read; seems not linked to caching. For sure better resource stability without caching, considering my limited ram on the Synology (it has the max possible of 6Gb already)

[TheDreadPirate]

Are you videos H265 in mp4 containers?

[zaudio]

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

Yes, I've ready about ENTRYPOINT and CMD... but no clue yet how and where to use those. If I export my container's settings, there is a "cmd" : "" row in the key value pairs list... I tried putting mount -a in there but it just crashed the container on startup. And on that, advice to anyone reading this: DO NOT ENABLE AUTO RESTART on your container when mucking with it! That can be hard to recover from if it crashes on start!
Starting and stopping containers is all handled in the gui... but there may be a way to do it with task scheduler when the entire device reboots, which would be sufficient as long as the JF container keeps running.
One opther ting I forgot to mention is I'm having to run it --privileged to be able to do those mounts.... I tried adding the recommended capabilities that got me past missing capability messages, but without --privileged I just get 'permission denied'.... I have read about adding --security-opt apparmor:unconfined that might help with this, but could not get that to work using my export/import settings method to change stuff... perhaps again if I start the container using the task scheduler and a docker command I can add that??? I just wanted to test out the performance of different mount points to see if they even help before getting bogged down in improving the setup.
As it is, on upgrading my JF container I may have to redo the additional setup... unless I can just use an apt update and install to do it?

---

Are you videos H265 in mp4 containers?

for 4k UHD they are H265 or HEVC in mkv containers

[zaudio]

So was just watching 'The Flash'... all went well till 37 mins in... 0.5 second 'pause' in video and audio... nothing in the logs.
Then an hour in movie totally paused for seconds... then stuttered slowly forwards till I stopped it.
I immediately connected to my JF container and grabbed the logs.
So at that 37 min point, nothing in the logs... so ???
But just a minute before all everything went wrong, a media library scan task fired! Like why are those set to run during the day???
So I am now editing ALL the JF tasks in the settings to times when I'm definitely asleep.... or disabling ones I do not need... like the subtitle task and chapter images.
Also going to check all tasks on my NAS, on my shield (plex for example; checking that seems sensible, only runs tasks 4am to 7am)... kind of obvious now I discovered this.
Hoping this could be final the missing link here - explaining the disconnects I've had before etc. Annoyingly that scan task was set to run at 21:54 each evening, so would overlap a lot of my movie watching times. The better share mounts I have now also has been helping stabilize playback for sure... I had so many more small glitches before.
After doing the above, not a single glitch watching the final 80 mins of the movie... so fingers crossed.
Perhaps with running JF on a lower resource device you just have to find all the rats and eliminate them. The hardware I have is for sure capable of streaming anything I throw at it... so we'll see.

[zaudio]

AND the next rat... by default JF containers are in UTC time (hard to spot this as the web interface shows activities in local time)
So this means scheduled tasks execute at the wrong time if you do not know this.
It's fixed by adding another environment variable to the container, for me this was:
TZ Canada/Mountain
Then in Terminal
date
returns the correct local time and I'm thinking my tasks will now run as I want them... fingers crossed again. I just had another 10pm interruption running my 4am scan media library task lol.
Until then, everything was buttery smooth. So I thinking I'm winning. But I totally understand why others have issues with getting performance where it needs to be when running JF from a docker container.

[Deleted User]

good to hear it's been smooth other than tasks consuming resources (but you've got that handled)

[zaudio]

So far maybe. I did test play another movie ('The Matrix') after restarting my container for the time zone fix, and it was not playing well at all... unsure why. Anyway I reset everything and called it a day. Will watch that same movie file soon to verify if is actually OK via JF. As usual rewinding and replaying 'bad play' sections then play totally fine... so the file is fine. I even checked that disk for fragmentation... none.
For sure JF on my NAS seems very temperamental but playing media directly using my Zidoo player is not... I am just hoping I can get it to a place where I can use it with some confidence, as I much prefer the interface and playback tracking.

[zaudio]

So far maybe. I did test play another movie ('The Matrix') after restarting my container for the time zone fix, and it was not playing well at all... unsure why. Anyway I reset everything and called it a day. Will watch that same movie file soon to verify if is actually OK via JF. As usual rewinding and replaying 'bad play' sections then play totally fine... so the file is fine. I even checked that disk for fragmentation... none.
For sure JF on my NAS seems very temperamental but playing media directly using my Zidoo player is not... I am just hoping I can get it to a place where I can use it with some confidence, as I much prefer the interface and playback tracking.

Sadly I continue to get the smaller glitches often enough despite all the optimizations I made. I can only conclude that I cannot stream my media (particularly UHD) through JF server on my Synology Nas's container to my Zidoo Z9x and expect glitch free playback.
I never experience these glitches playing using the Zidoo player directly... 
There is clearly a limitation here with my setup that would be avoided by being able to also play my media truly directly when using the JF UI. Just hoping now the JF team will add the feature I asked for. Until then I'm going to skip using the official JF client as I find the glitches take me out of the movies... Even one glitch in a movie is more than I would expect. Sucks.
I will give this fork of the JF client a go before I totally give up (it might allow the direct path I need), but I'd like to be able to use the latest JF apps: https://github.com/Andy2244/jellyfin-androidtv-zidoo
Thanks for the help and advice though... shame I could not 100% resolve my problem with just that.
UPDATE: Andy's JF Zidoo client fork from late 2022 works! Direct play to external player using the direct network path setup for the libraries... Just as I want. Let's hope the JF team add the same feature, as Andy is no longer supporting that Fork, and it's always good to get the latest features.

[Deleted User]

at least you know you did everything possible

i looked over andy's fork to try and locate what they changed specifically but the change list is very large because it hasn't been updated in so long

if you spent some time you might locate the minimum changes that are actually required and then port them to the updated code so you're not very far behind

[zaudio]

Sadly Andy's fork using Direct path has some minor bugs that won't now get fixed.... hence my wanting to use the official Android TV version. Maybe one day. I did see the Emby guys might update their client to support the Zidoo, so that could be a possibility one day also. Andy's works well enough for now.