Force Higher Bitrates

[Happy2Play 8296]

I have been reluctant to post logs here because I figured they would have my personal info in them. I did notice that they do IP address ports etc, should I PM them or something?

You can pm them or sanitize personal information and post.

[softworkz 3338]

I have been reluctant to post logs here because I figured they would have my personal info in them. I did notice that they do IP address ports etc, should I PM them or something?

 

I agree, I wouldn't do that myself. You are welcome to send your logs via PM!

[softworkz 3338]

Doesn't the majority of this come back to this?

 

https://emby.media/community/index.php?/topic/71791-auto-quality-always-low-bitrates/?p=776790

 

No. The conversation you're referencing was about the automatic bandwidth detection which is used when a user chooses the 'Auto' setting for bandwidth in the player.

 

The user (indirectly) confirms that he can switch to a discrete bandwidth setting to get higher video bitrates, so that's not what it was about. What actually happened was that the automatic bandwidth detection did not work and finally a hardcoded default value had been used (1.5Mbps). Meanwhile that value has been increased to 3.0Mbps.

 

But that's not the same as what this conversation is about.

[Jonathan1683 24]

Thanks Soft I sent you and Luke the logs. Appreciate the assistance currently a user is logged in and only getting 1.5

[Happy2Play 8296]

No. The conversation you're referencing was about the automatic bandwidth detection which is used when a user chooses the 'Auto' setting for bandwidth in the player.

 

The user (indirectly) confirms that he can switch to a discrete bandwidth setting to get higher video bitrates, so that's not what it was about. What actually happened was that the automatic bandwidth detection did not work and finally a hardcoded default value had been used (1.5Mbps). Meanwhile that value has been increased to 3.0Mbps.

 

But that's not the same as what this conversation is about.

 

So everyone that defaults to 1.5Mbps on Auto, means the bandwidth detection system failed to detect their proper bandwidth?  As that would appear to be the case in multiple topic.

 

Yes I see that it has been increased in Beta to 3.0Mbps.

[softworkz 3338]

So everyone that defaults to 1.5Mbps on Auto, means the bandwidth detection system failed to detect their proper bandwidth?  As that would appear to be the case in multiple topic.

 

I doubt that a distinct and rounded value like 1500000 would be the result of a detection method and at the same time - just by coincidence - precisely match the fallback value.

So in those cases it's very likely that the bandwidth detection didn't work.

[softworkz 3338]

Important note for occasional readers: This is about the in-app setting "Automatic" for playback quality.

 

The topic title is a bit misleading: Users can always make their own choice during playback to "force" higher bitrates

 

 

@@Jonathan1683 - Thanks for sending the logs. To be sure what this is about, I needed to see what the client requested and what the server delivered and that it matches the problem description

 

 

The logs showed: In both cases it actually appears that the automatic bandwidth detection did not work and the default value of 1.5 Mbit was chosen.

 

That means, we got two issues here:

• Emby Web: Automatic Bandwidth detection does not work on Safari
  .
• Apple TV: Automatic Bandwidth detection does not work

 

Please create topics for each issue in the corresponding forum sections.

(you should be the OP, otherwise I had created them for you)

 

 

Some more notes:

 

Encoding Quality Settings (CRF)

 

The topic title wasn't chosen well and there were no logs included, that's why earlier in this topic it seemed to be that this was about bitrates delivered by the server being less than what the client had requested. This is in fact a known problem but it turned out that it wasn't the issue here.

 

 

Server Bitrate-Limit Options (overall and per-user)

 

Like the name already indicates: These are upper limits only and do not have any other effect on client streaming bandwidth.

[pir8radio 1292]

I dont even see emby doing the speed test anymore for the auto function, just curious how you guys are doing that now, wanted to look at it. 

[Luke 37094]

Many devices have bandwidth estimation apis now.

[pir8radio 1292]

Many devices have bandwidth estimation apis now.

 

ah...  was looking at chrome,    used to see the two or three large file downloads for the bandwidth test...     Just curious.

[softworkz 3338]

Many devices have bandwidth estimation apis now.

 

The NetworkInformation API isn't widely supported by browsers (no Firefox, no Edge, no IE, no Safari), maybe it might make sense to fall back to the manual bandwidth test for those?

[pir8radio 1292]

ahh that is a neat way to do it, didnt know the downlink attribute existed, i assume that is what you are using?

Edited January 11, 2020 by pir8radio

[cptlores 23]

Which method is used for Auto is almost irrelevant. The point is that your number one task (video playback) is frequently behaving in a subpar manner when using default settings.

Edited January 11, 2020 by cptlores

[softworkz 3338]

@@cptlores - I agree. It simply needs to work in one or another way.

 

Though, this forum is about the server and it is not a server issue. 

I can only recommend to create topics in the appropriate client forums like I suggested above.

 

Just a friendly hint:

• General Forum: "Auto-mode frequently doesn't work" ==> low probability to succeed
  .
• Clients > Web App Forum: "Automatic bandwidth detection does not work in Safari Browser" ==> high probability to get resolved

[cptlores 23]

It is not limited to the webplayer. It is also happening on pretty much any device like chromecast, iOS, tvOS etc.

And if the devs can't work on the problem without having the discussion placed in the "correct" forum section, I suggest this thread and others like it should be moved to wherever the "correct" place may be.

Edited January 12, 2020 by cptlores

[softworkz 3338]

And if the devs can't work on the problem without having the discussion placed in the "correct" forum section, I suggest this thread and others like it should be moved to wherever the "correct" place may be.

 

It's not about moving this conversation. Moving this conversation wouldn't be helpful for anyone, it would only create confusion.

 

Instead we need to look at specific examples that are documented by users, allow us to reproduce the situation and work on improving or fixing it - each in its own conversation.

Bandwidth detection is working fine in many apps and each case where it doesn't work needs to be looked at individually. Different apps, different developers, different server deployments, different client setups, etc.. We cannot handle all in a single conversation - that never ends well and only attracts even more users adding their off-topic issues to the mix.

 

 

Besides that, I'm wondering what made you do the exact opposite of what I was trying to suggest in my previous message?

First I thought you were joking and I replied with something funny, but then you edited your response and it appeared you were serious - so I deleted my original response...

(for those that might have seen it in their e-mail notifications)

[cptlores 23]

You can't expect users to have the inside information and/or skill set to accurately identify the source of a problem and always post in the "correct" place. Most people (me included) will just look for existing thread topics that fit their problem, and post there instead of starting a new one.

 

And yes I've sent my logs back in august, when the same Auto problem was previously discussed.

[Jdiesel 1114]

It has been brought up many times and it never goes anywhere. There isn't even a common thread to track the issue.

 

https://emby.media/community/index.php?/topic/66020-auto-quality-needs-work/

 

https://emby.media/community/index.php?/topic/80447-emby-server-auto-quality/

 

https://emby.media/community/index.php?/topic/59895-auto-quality-not-adjusting/

 

https://emby.media/community/index.php?/topic/71791-auto-quality-always-low-bitrates/

 

https://emby.media/community/index.php?/topic/78967-auto-quality/

 

https://emby.media/community/index.php?/topic/60224-auto-quality-stuck-at-480p/

 

https://emby.media/community/index.php?/topic/45980-auto-bitrate-not-so-good/

[Guest asrequested]

I stopped using auto a long time ago. It's never worked as desired, for me.

[softworkz 3338]

You can't expect users to have the inside information and/or skill set to accurately identify the source of a problem and always post in the "correct" place. Most people (me included) will just look for existing thread topics that fit their problem, and post there instead of starting a new one.

 

And yes I've sent my logs back in august, when the same Auto problem was previously discussed.

 

I'm not closely involved with client development, so I don't even know much about the history of this subject.

 

What I wrote was meant as a general advice and it was not primarily about posting in the 'correct' place, but I wanted to explain that a very specific and detailed problem report has much better chances to get picked up than general and unspecific reports.

 

I highly appreciate all user effort, and when I hinted that posting in this specific conversation is a dead end (@Jdiesel) - I just meant to avoid wasted effort and show the most effective way to get a problem resolved.

[cptlores 23]

I stopped using auto a long time ago. It's never worked as desired, for me.

And for enthusiasts like us, that works fine. But regular users will and should use Auto since they likely do not have the knowledge to make educated choices about resolution and bitrate. And so the end result is lot's of unnecessary transcoding and comments like "Emby video looks weird, Netflix is better".  In fact, at this very moment I am looking at 3x transcode sessions with the infamous "1.5Mbit" quality, while knowing the clients in question has the bandwidth to direct stream.

Edited January 12, 2020 by cptlores

[softworkz 3338]

And for enthusiasts like us, that works fine. But regular users will and should use Auto since they likely do not have the knowledge to make educated choices about resolution and bitrate. And so the end result is lot's of unnecessary transcoding and comments like "Emby video looks weird, Netflix is better".  In fact, at this very moment I am looking at 3x transcode sessions with the infamous "1.5Mbit" quality, while knowing the clients in question has the bandwidth to direct stream.

 

I 100% agree - down to every single letter. 

 

But I'm really getting desperate wondering why I seem to have failed to explain the situation in an understandable way.

I'll give it one last try:

 

• What's happening here is like people are sending their Christmas wish-list to the Easter bunny instead of Santa Clause

  .

• The Easter bunny might read that wish-list and even tell when it likes certain wishes.

  .

• But the Easter bunny does not work on Christmas because it goes on vacation during that time each year.

  .

• The Easter bunny and Santa Clause are good friends but each of them has his own load of work to handle. 

  .

• That's why Santa Clause doesn't have enough time to regularly jump into his one-horse open sleigh, ride to the Easter bunny's house and read through all of the Easter bunny's mail to check whether there might be some incorrectly addressed Christmas wish-lists.

  .

• On the other side, when the Easter bunny would encounter a misdirected Christmas wish-list, it could easily forward it to Santa Clause

  .

• Though, when a wish is pretty unspecific like "everything in my life is going wrong - I wish something good" - the Easter bunny knows that it would only end up in the Santa Clause shredder

  .

• That's where the Easter bunny decides to return the mail back to sender with some advice attached how to properly send the wish-list to the right department at the Santa-Clause center

  .

• But when the sender ignores that hint and keeps sending his Christmas wishes to the Easter bunny - what will happen?

  .

  => Obviously: There will be no Christmas presents under the tree!         

[Guest asrequested]

But the thing is, that this has failed in every app that I've tried. That would suggest something fundamental. So am I to make the same report in every app forum? That seems redundant. I've even had this happen in my 10g LAN with my HTPC running Theater with mpv. It actually made the server transcode.

Edited January 13, 2020 by Doofus

[softworkz 3338]

But the thing is, that this has failed in every app that I've tried. That would suggest something fundamental. So am I to make the same report in every app forum? That seems redundant. I've even had this happen in my 10g LAN with my HTPC running Theater with mpv. It actually made the server transcode.

 

Focus on one specific case, e.g. the one that is most important to you or the one which is easiest for you to document.

[BAlGaInTl 279]

I ran into this issue over the weekend when I was visiting my parents.  I had to manually set the rate on their Roku TV or it looked like crap.

 

I agree that it's easy for an advanced user... which my parents are not.

 

Maybe there could be an option server side that is overall or per user that tells Emby to ignore the app rate if set to Auto or > a defined cap.  That internet streaming bitrate limit already exists on a Global and User level.  Adding an advanced toggle for an admin for ignoring local limits globally or per user could be very useful in the interim.  If enabled, The server automatically shoots for that speed.  If it can direct stream within that limit, it does.  If it needs to transcode... it will, but to that level.