Jump to content

Shield Experience 9 Release


CBers

Recommended Posts

rbjtech
37 minutes ago, rbjtech said:

So I'm making progress...

It' appears to be a cpu/thread limitation - I'm not sure if the http engine is multi-threaded, but I'm now running Emby with Direct Attached Storage on an old i3 (12Gb Ram) - reduced to 2 cores (hyperthreading disabled) and reduced to 1.2Ghz (as low as it would go), the 6 x 4K (~400-600Mbit/sec) test streams are now choking / stalling (but not stopping).  Interesting, the CPU is not anywhere near Max and nor are the disks - so something is choking the streams ..    This test simulates Emby Server running on a NAS.

Next is to add SMB read into the mix (ie remove Direct Attached Storage) .. this will simulate Emby running on a Shield using a NAS as the storage.  I think this will be a worst case scenario.. predictions ?

Hmm - tbh not what I predicted, but SMB access to the Server and then HTTP delivery was faultless ...

6 x 4K Remux streams running on a dual core i3 CPU @ 1.2Ghz - that's a full Duplex Ethernet stream averaging between 400-500Mbit. 😬

Local disk I/O is 0% - as this is all running from a 'NAS' (a Windows File Share).

That is pretty impressive tbh.

I have no idea why this is working better than direct file access, maybe emby is more efficient with data in the network stack as opposed to local disk I/O ?  Who knows.

The last test I'd like to do is run Emby on the Shield itself - never done this before.  if that chokes, then we know the issue is likely the Shield itself as opposed to the 'HTTP' vs 'SMB' debate ...

More to follow ...

 

image.thumb.png.2b6f178ab84c9d57c1619c54acdd3971.png

 

 

  • Like 3
Link to comment
Share on other sites

magicgg91

Hello,

For me, Direct Access is important, when I start reading a media, and Emby server goes down for any reason, media continues to play until end !
With HTTP, it continues only from the buffered media.
That doesn't occur often, but in those cases, it's very useful to not be disturbed during media playing and have to put the hands in motor, not funny with family waiting to continue to watch their media ....

As other apps has found workaround and it's now working fine for them, I don't see how Emby can't sold this issue.

Link to comment
Share on other sites

Unfortunately, unless something changes with the Shield firmware that doesn't require these unnecessary permissions (such as write or manage storage access) this option will have to be removed.

I was apprehensive about adding such permissions to the app but I decided to try it just to see if it would actually solve the problem.  However, upon uploading that package to the Play Store, it was then required that we mark the app in the store as having "Extremely sensitive permissions" and having "All File Access".  I'm simply not going to do that.  Those two warnings would certainly keep me from installing an app that is supposed to just be playing my media.

  • Thanks 1
Link to comment
Share on other sites

Audiomixer

So how does an app like kodi accomplish this? They simply have “allow” and “don’t allow” and this works fine. They even allow NFC as well as smb.

Edited by Audiomixer
Link to comment
Share on other sites

1 hour ago, FrostByte said:

You would think there would already be a lesser option available to just access w/o modifying

There is.  it is called "READ_EXTERNAL_STORAGE" and the app already has that permission.  But it only works for Frostbyte apparently.

Link to comment
Share on other sites

FrostByte
Just now, ebr said:

There is.  it is called "READ_EXTERNAL_STORAGE" and the app already has that permission.  But it only works for Frostbyte apparently.

Well, I am special you know.

  • Like 1
Link to comment
Share on other sites

55 minutes ago, Audiomixer said:

So how does an app like kodi accomplish this? They simply have “allow” and “don’t allow” and this works fine. They even allow NFC as well as smb.

I do not know.  That app is a totally different animal really but, as I've stated a number of times already, I've already spent more time on this than is warranted by the benefit it provides at this time.

Link to comment
Share on other sites

FrostByte
1 hour ago, ebr said:

There is.  it is called "READ_EXTERNAL_STORAGE" and the app already has that permission.  But it only works for Frostbyte apparently.

Every other app that is working though connects to my NAS and opens a smb connection.  I can see in my logs every time these apps connect.  ATV is not opening an smb connection, but somehow connecting anyway.

This what I see from VLC and MX player when I start playing media.  I get nothing from ATV.  This is why I think it takes so long to start, because it's not opening up smb

User [Rick] from [(10.0.0.7)] via [CIFS(SMB3)] accessed shared folder [MyEmbyMedia]

 

  • Agree 1
Link to comment
Share on other sites

CBers
1 hour ago, ebr said:

I do not know.  That app is a totally different animal really but, as I've stated a number of times already, I've already spent more time on this than is warranted by the benefit it provides at this time.

Have you spoken to Nvidia, or even Google to try to resolve this? 

Perhaps they already have a solution. 

 

Link to comment
Share on other sites

usnscpo

Just adding my wish for this issue to get fleshed out.  I really prefer playing files direct, especially when I open up my 920+ emby server to my family/friends (who are gonna get much of my media via transcode).  I don't want to have my media consumption impacted by their streams if it can be helped.

  • Like 2
Link to comment
Share on other sites

rbjtech

I've given up trying to persuade Eric that it has it's genuine use cases.

Unless there is good reason to upgrade, On my Shield Pro (used exclusively for 4K remux playback only) I'm sticking with Android 9 and the latest Emby Beta which had DFA - as everything works perfectly. 

It may change in the future once the Android 11 permission model is better understood - we can always hope. ;)

  • Agree 2
Link to comment
Share on other sites

FrostByte

If I read the release notes correctly you can still upgrade the app if you're on Android 9 because it checks the OS version before disabling the option.  However, I would keep the .66 apk just in case.

  • Agree 1
Link to comment
Share on other sites

51 minutes ago, FrostByte said:

you can still upgrade the app if you're on Android 9 because it checks the OS version before disabling the option

That's correct.  The option is only limited on 11+

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

usnscpo

I can certainly sympathize with needing to manage support time constraints.  You're trying to run a business, after all.

Might I suggest making DFA an "unsupported advanced feature" or plugin, with caveats that it won't be supported by the staff?  Then we users can work among ourselves here?

I have hopes that something will change that would permit your code to open this feature back up.

Edited by usnscpo
  • Like 1
Link to comment
Share on other sites

rbjtech
46 minutes ago, ebr said:

That's correct.  The option is only limited on 11+

Ah - that's good news - the best of both worlds. 

Thanks for accommodating those that have not upgraded / or downgraded.

Android 11 appears to have brought nothing but grief !

Link to comment
Share on other sites

15 minutes ago, usnscpo said:

Might I suggest making DFA an "unsupported advanced feature" or plugin, with caveats that it won't be supported by the staff?

Hi.  Unfortunately, something like that is not easily done on a platform like Android.  You can't just easily edit a config file.

16 minutes ago, usnscpo said:

Then we users can work among ourselves here?

Also, unfortunately, it never really works that way. What happens is someone comes in here and reports that playback isn't working.  Then we spend time getting logs and tracing what the issue is and eventually find out that they have set this option and that's why.  All of that burns valuable time and is one of the reasons we try to keep options to only the ones that are less likely for people to shoot themselves in the foot with.

Link to comment
Share on other sites

usnscpo

Thanks for the reply ebr.  I can see that. 

So I'm really close to trying to roll back to Android 9 on the shield.  If I do chances are high that I will bork this, but this is how I learn, eh!  Wish me luck!

  • Like 1
Link to comment
Share on other sites

CBers
18 minutes ago, rbjtech said:

Android 11 appears to have brought nothing but grief !

No problems here with either SE9.0, or SE9.0.1.
 

  • Like 1
Link to comment
Share on other sites

rbjtech
19 minutes ago, usnscpo said:

So I'm really close to trying to roll back to Android 9 on the shield.  If I do chances are high that I will bork this, but this is how I learn, eh!  Wish me luck!

Some of the online references are frankly incorrect - so if you haven't done this sort of thing before, if possible, I would test on an old Android phone to get the feel of adb and fastboot.

Getting your pc to recognise the Shield TV with fastboot is actually the most technical bit .. (or was for me).  In the end, I used Samsung USB drivers.  

  • Like 1
Link to comment
Share on other sites

On 2/5/2022 at 5:38 AM, rbjtech said:

I didn't get time yesterday to continue my in-depth testing - but could you just expand/confirm your setup where you have the issue ?

1. NAS > 1Gig Ethernet > Network Switch 

2. Shield Server > 1Gig Ethernet > Network Switch

3. Shield Client

If the above is correct, then it is exactly this sort of configuration where SMB makes complete sense and is a valid use case.

Using HTTP - the data path is : Shield Client > HTTP > Shield Server < SMB < NAS

Using SMB - the data path is : Shield Client < SMB < NAS

As Eric has alluded to above - there are 'many' variables/scenario's that contribute to this technical discussion - putting out statements such as 'mine works' and 'you don't need DFA' is unhelpful without the evidence to back it up.

Now I'm back to Android 9 on my Shield - I should be able to prove where DFA has a valid justification (or not) to be used - from the looks of it @caalin may have identified one scenario, but we need to confirm what is causing the hang. 

Update: first, I forgot to mention that I was still on SE 8.2. Second, the poor performance of HTTP streaming was due to "oplocks" being disabled for a couple of shared folders on my NAS. That thing actually messed with the DFA too, as in streams from those folders needed more than one minute to load up

With that said, DFA is still faster on high bit rate files. I tested with Tenet (62mbps) and skipping back and forward was instant with DFA, while, with HTTP it would take about a third of a second with automatic changing of the refresh rate and about double (so about half a second) without it. On the flip side, with DFA, streams take a little longer to start up, like  a second or two

  • Like 3
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...