4k Remux playback issues on Nvidia Shield TV

[FrostByte 5049]

I played with it some more last night and it seems to depend on the movie.  I tried all 20 movies in my new movies section on the Home Page and I would say roughly half would not play with just the External player box checked.  However, all of them direct play w/o External player checked and also all direct play with both External player and Direct Path checked.  

Of the ones that do not play at all with just External Player checked I usually get a real quick pop-up message (but not always) that disappears really quick, but it looks really close to the pics Audiomixer posted.  So far I've not been able to figure out any difference between the videos that won't play w/o the Direct Path setup.  It's all ripped UHD discs with a variety of DV/No DV, Subs / no Subs, etc.  

I did send logs though so maybe ebr can figure it out

[Audiomixer 328]

2 hours ago, rbjtech said:

@Audiomixer I'm not sure I'm fully following your latest investigation.

I think my behaviour is the opposite of yours & @FrostByte

If I select 'use External Player' and unselect 'Direct Play' - then I can play from Emby via VLC/X-PLore just fine - it's quick (1-2 secs) and it is using HTTP - it is not a SMB connection.

If I enable 'Direct Play' - then I get the error as per my post above. https://emby.media/community/index.php?/topic/94968-4k-remux-playback-issues-on-nvidia-shield-tv/&do=findComment&comment=1108733

To note - VLC did not work at all until I uninstalled/reinstalled it (and gave permissions for it to use the mounted storage) - this was AFTER Emby was installed.   The install order may have something to do with it ?

If using the native Apps - Both VLC/X-Plore play the file directly via SMB (instantly, no delay at all).

@rbjtech

If I select ‘use external player’ and unselect ‘direct play’…it plays via whatever player one chooses pretty much instantaneous. I hadn’t tried that.  I guess the kicker is that if direct path is checked and use external player is checked, nothing plays unless the optional shared folder is properly filled out on server.  Playback is instant.

Even after I had reinstalled VLC, Emby could not play anything using external player VLC (pass direct path off) unless VLC permission was set to allow all the time. Folders in VLC are empty otherwise. Also VLC was installed after Emby.

That is pretty much all I have on this subject.

 

[ebr 14912]

12 minutes ago, Audiomixer said:

nothing plays unless the optional shared folder is properly filled out on server

Right as that is how the app knows what the proper direct path is.  That is not new.  That is always how this has worked.

13 minutes ago, Audiomixer said:

f I select ‘use external player’ and unselect ‘direct play’…it plays via whatever player one chooses pretty much instantaneous

More evidence that the direct path option may not be needed anymore.

13 minutes ago, Audiomixer said:

Emby could not play anything using external player VLC (pass direct path off) unless VLC permission was set to allow all the time

If you are using an external player and passing the direct path, then Emby is completely out of the equation.  Permissions in Emby would make no difference as it is the external player app that is trying to access the file location, not Emby.

[rbjtech 4260]

@ebr I'm not sure why you keep using the term 'evidence'.  Nobody here is suggesting this does not work via HTTP - on our higher end hardware, we have no issues using HTTP but what happens on say a lower end NAS using the Shield with HTTP and multiple 4K sessions - does it perform ?

On many occasions (I can find the threads if you need them), File Access has solved the issues of low powered NAS being unable to stream 4K Remux reliably.   They simply do not have the CPU to do the HTTP streaming + other emby tasks such as a library scan.  With SMB they don't have to.

The other point to note, is scalability (does HTTP work with 10-15-20 sessions?) and future needs - what about 8K ?  Does HTTP work ok with 400Mbit/sec - I would bet it would cripple a NAS while File/SMB directly would bypass this bottleneck and have a much better chance of performing as you are, in effect, offloading the worker.

At the end of the day, this (was..) a welcome 'Feature' that emby had over it's competitors - for the tiny amount of extra support it created - why remove it ? 

Edited January 20, 2022 by rbjtech

[FrostByte 5049]

Do apps that get spawned from other apps have the same permissions as they would have if they were started separately by the user?  Or, are they restricted to the permissions of the app which is doing the spawning?  I would think for security reasons they would only inherit the permissions of the app that's spawning them.   I'm probably overthinking the Android security.

Edited January 20, 2022 by FrostByte

[rbjtech 4260]

3 minutes ago, FrostByte said:

Do apps that get spawned from other apps have the same permissions as they would have if they were started separately by the user?  Or, are they restricted to the permissions of the app which is doing the spawning?  I would think for security reasons they would only inherit the permissions of the app that's spawning them.  

A good question - and I think this may be related to the 'Allow Only for this Session' vs 'Allow Always for this App' options (the 2nd of which Emby does not have..) ?

[ebr 14912]

23 minutes ago, rbjtech said:

for the tiny amount of extra support it created

That's not what I'd call this discussion... and, to get this working properly requires quite a bit of configuration in multiple places.  It isn't just throw a switch.  So, every time someone wants to turn this on (and it doesn't seem to work) we have to go through pointing them to all of that configuration that needs to be completed properly.  For a feature that benefits an extremely small audience, it has an inordinate support load actually.

25 minutes ago, rbjtech said:

I'm not sure why you keep using the term 'evidence'.

Because there has been more than one report that situations where this previously solved a problem, that problem was no longer there with the http delivery method.  So, unless we can be sure that this direct file method is even helping that small subset of users, it isn't worth trying to continue to support it.

 

[ebr 14912]

6 minutes ago, FrostByte said:

Do apps that get spawned from other apps have the same permissions as they would have if they were started separately by the user?  Or, are they restricted to the permissions of the app which is doing the spawning?  I would think for security reasons they would only inherit the permissions of the app that's spawning them.   I'm probably overthinking the Android security.

Our app doesn't "spawn" anything.  We ask the Android system to play a particular URI and then it takes over from there.  Everything is under the control of Android and the permissions are solely the ones for the app doing the actual access.  So, using an external player and a direct path means no Emby permissions are relevant at all because we aren't involved.

[FrostByte 5049]

I'm sure you're right, but I still think if Bob doesn't have permissions to play something then he shouldn't be able to ask that they be played by someone else either.  That would probably make things too difficult though

[rbjtech 4260]

21 minutes ago, ebr said:

That's not what I'd call this discussion... and, to get this working properly requires quite a bit of configuration in multiple places.  It isn't just throw a switch.  So, every time someone wants to turn this on (and it doesn't seem to work) we have to go through pointing them to all of that configuration that needs to be completed properly.  For a feature that benefits an extremely small audience, it has an inordinate support load actually.

If HTTP works for them, they will not even enable this function - it's users who have a problem that are asked to try this alternative method - usually resulting in the problem being resolved.  So by removing even the option, you are removing a feature that allows some users to play higher end media.  I'm not sure how that can be a good thing for Emby ?

[ebr 14912]

1 hour ago, ebr said:

Because there has been more than one report that situations where this previously solved a problem, that problem was no longer there with the http delivery method.

So, we need to be sure the problems still exist before worrying about solving them.

[Riggs 300]

@ebr

Thinking in the future... and looking your speech about direct path or optional path or whatever name is... and delete that feature...

Exoplayer can handle any format and you can give us confidence to not worry about it?

Is good idea put all eggs in one spot?

What happens if Exoplayer fails in some point? 

I remember a lot of issues with Exoplayer.... I'm just saying...

[FrostByte 5049]

Options are always good. 

Exoplayer still can't deal with movies like the extended versions of The Martian or Blackhawk Down where the audio and video are out of sync right on the disc.  So, I end up using an external player for those. 

HTTP may be good or better than it used to be, but direct should always be better if working properly.

Most people don't need these options, but both are nice to have

Edited February 9, 2022 by FrostByte