EASY REQUEST - Client Bandwidth Feedback

[pir8radio 1301]

Often times when I see "Reason for transcodng: Media bitrate exceeds limit." in the info I wonder, what kind of internet connection do they have?   I know this can cover multiple scenarios like bandwidth limit set for user, server, client side quality setting, as well as AUTO bandwidth detection...     Can you PLEASE add to the dashboard the returned client bandwidth capabilities?   The value you are getting from the client that tells emby its bandwidth abilities.   

 

While you are at it tighten up the spaces between lines on the transcode items, and align the results to the right instead of center..   

 

MAYBE SOMETHING LIKE THIS  :

 

Edited February 16, 2020 by pir8radio

[Luke 38500]

Hi yes it's a good idea. Thanks.

[saltedhash 4]

x2 on this request. I would love to see that as well! Sometimes when I see a low negotiated bandwidth, I think it could be my end and I endlessly try to look into why it is occurring when it usually is the client side connection.

[maegibbons 1267]

The more info the better on direct play/transcoding. I would like to see a pop up giving the full stats for nerds info from the client.

 

Krs

 

Mark

 

Sent from my SM-N976B using Tapatalk

[mastrmind11 717]

and this https://emby.media/community/index.php?/topic/61430-emby-server-bitrate-on-admin-page/

[saltedhash 4]

and this https://emby.media/community/index.php?/topic/61430-emby-server-bitrate-on-admin-page/

 

I just put a post in that thread as well and liked your first post. Looks like it's been out there for 2 years now though so not sure if we'll get either of these anytime soon

[rbjtech 4772]

Bumping this - as I'm seeing many requests of failures caused by 4K REMUX's where the people simply do not have enough bandwidth (for whatever reason) to play the files.

If as per @pir8radio requested a couple of years go - if you put the available client bandwidth on the dashboard (download a sample file when they first connect and store it ? But dynamic /live would be even better) then people can see how good/bad their connection is vs what they are trying to play..

[pir8radio 1301]

On 6/22/2020 at 7:33 AM, rbjtech said:

Bumping this - as I'm seeing many requests of failures caused by 4K REMUX's where the people simply do not have enough bandwidth (for whatever reason) to play the files.

If as per @pir8radio requested a couple of years go - if you put the available client bandwidth on the dashboard (download a sample file when they first connect and store it ? But dynamic /live would be even better) then people can see how good/bad their connection is vs what they are trying to play..

 

to be clear I would just like them to display what the "perceived" bandwidth is...  as in what feedback emby server gets from the client side that says XXX mbps.   I know its hard to get real, actual available bandwidth.   But the hard part is understanding what emby even thinks the client bandwidth is....   This should be super easy right?   the client sends its perceived bandwidth value over to the server today, we just need to display that on each users tile when playing something.   

[ebr 15352]

11 hours ago, pir8radio said:

the client sends its perceived bandwidth value over to the server today,

Not exactly.  It sends a limit.  That could come from detection or the user selecting it.

[pir8radio 1301]

2 hours ago, ebr said:

Not exactly.  It sends a limit.  That could come from detection or the user selecting it.

that would be what we would want to see...    right now im blind to what the client is telling the server its top bandwidth is.  

[ttgapers 94]

+1 for this.

I am noticing transcoding happening on 4k HEVC files that Direct Play no problem (with multiple/simultaneous users online) once I set the Emby Fire TV 4k client to 10 Mbits/sec. Once set to Auto it attempts to transcode to 1080p. Getting to the root of the issue got me to this thread first with me wondering "how" or "where" I can see "what" the server believes the max streaming bitrate per client to be.

Note: Prior to manually setting the max bitrate, the client with default to 1080p. Once I changed the max bitrate, it defaults to 4K as well.

Thoughts? Maybe we are too conservative on our calculations? I guess I could also upload my logs/start a new thread for this. Please advise.

 

 

Edited December 27, 2020 by ttgapers

[RanmaCanada 411]

I would like this as well as I am sick and tired of "media exceeds bitrate" and all my friends and family being throttled to 3mbit when they and I, have more than enough bandwidth.  It seems every time the client is updated, it resets whatever manual setting we have put up back to auto and auto doesn't appear to work very well.

[ebr 15352]

9 hours ago, RanmaCanada said:

It seems every time the client is updated, it resets whatever manual setting we have put up back to auto

What client?  That shouldn't be the case for apps as their settings are persistent - unless you uninstall them.

[RanmaCanada 411]

13 hours ago, ebr said:

What client?  That shouldn't be the case for apps as their settings are persistent - unless you uninstall them.

I have found it happening with Roku, FireTV and Apple TV, but not with every user.  I will contact my friends/family and inform them they have been throttled to 3mbps and then walk them through manually changing the settings from auto to something high, like 40+ (I have gigabit upload and they all have at least 100mbps down speed, so it doesn't matter), and they will be good for a week or at most a month, and then they are back to being at 3mbps.  I have even had an instance where someone was locked at 1.  Would you need logs from my end, or their end (which would be extremely difficult to do but I can try!)  

Is it possible their ISP is hardcore throttling (traffic shaping with deep packet inspection) Emby and creating a total crap connection?  

[Luke 38500]

1 hour ago, RanmaCanada said:

 

Is it possible their ISP is hardcore throttling (traffic shaping with deep packet inspection) Emby and creating a total crap connection?  

Some ways to test this would be to try a different public facing router port and/or setup SSL. If one of these two resolves it then it's likely there was some throttling occurring.

[rbjtech 4772]

Just giving this another bump.  With 34 likes, it's gaining traction.

2021-02-16 12:03:50.802 Info App: Bitrate exceeds DirectPlay limit: media bitrate: 9723347, max bitrate: 385000

2021-02-16 12:03:50.802 Info App: Bitrate exceeds DirectStream limit: media bitrate: 9723347, max bitrate: 385000

2021-02-16 12:03:50.802 Info App: RemoteClientBitrateLimit: 15000000, RemoteIp: a.b.c.d, IsInLocalNetwork: False

It would also be useful if the reason for the transcode was the remoteClientBitrateLimit - in my case, I have set a 15Mbit limit for this user.

In the above example, emby thinks I have 385 Kbit/sec available (!), but on a speedtest, I have 3.5 Mbit/sec available (poor 3G connection).

On Client Auto - there is nothing I can do, but if I force the client to 3Mbit - the file plays at 3Mbit/sec just fine.

Having this info displayed is so much more important the transcoding position data imo - which frankly, I have never looked at...

Thanks.

 

 

[GrimReaper 3746]

54 minutes ago, rbjtech said:

Just giving this another bump.  With 34 likes, it's gaining traction.

2021-02-16 12:03:50.802 Info App: Bitrate exceeds DirectPlay limit: media bitrate: 9723347, max bitrate: 385000

2021-02-16 12:03:50.802 Info App: Bitrate exceeds DirectStream limit: media bitrate: 9723347, max bitrate: 385000

2021-02-16 12:03:50.802 Info App: RemoteClientBitrateLimit: 15000000, RemoteIp: a.b.c.d, IsInLocalNetwork: False

It would also be useful if the reason for the transcode was the remoteClientBitrateLimit - in my case, I have set a 15Mbit limit for this user.

In the above example, emby thinks I have 385 Kbit/sec available (!), but on a speedtest, I have 3.5 Mbit/sec available (poor 3G connection).

On Client Auto - there is nothing I can do, but if I force the client to 3Mbit - the file plays at 3Mbit/sec just fine.

Having this info displayed is so much more important the transcoding position data imo - which frankly, I have never looked at...

Thanks.

 

 

I reckon it just got few more upvotes by you pulling it on top of the FR list.