4K HEVC shows as 1080p, think I can't find any setup to fix?

[Luke 43009]

We are looking into the issue of this showing as 1080p. It is an edge case due to the cropped resolution so we will have to account for that. Thanks.

[Teddyknuddel 144]

17 minutes ago, Luke said:

We are looking into the issue of this showing as 1080p. It is an edge case due to the cropped resolution so we will have to account for that. Thanks.

Why aren’t you answering my question? Have I hit a sore spot?

[averrkn0t 7]

All my quality settings are, and had always been set to Auto, and everything worked fine until 5he latest updates. I reported this same 4K issue a couple of days ago. This issue started for me after updating to the lastest 3 versions. It's even reporting 4k as 720p in some cases, and  4k media stutters horribly.

The only workaround for this issue to get 4k working, was to manually set the quality to 4K-40mbp in quality settings, otherwise...This is how 4k media plays  (Attached) 

Hope this gets fixed soon.

 

Edited Wednesday at 06:22 AM by averrkn0t

[Teddyknuddel 144]

8 minutes ago, averrkn0t said:

Hope this gets fixed soon.

Forget it – the admins here just make promises without ever implementing a solution or keeping their word

[Teddyknuddel 144]

@Luke

Same as always – NOTHING is changing!

[ebr 16674]

On 9/3/2026 at 5:49 PM, Teddyknuddel said:

@Luke

Same as always – NOTHING is changing!

We've already adjusted for this situation.

Please stop spreading mis-information.

[Teddyknuddel 144]

1 hour ago, ebr said:

Wir haben uns bereits auf diese Situation eingestellt.

Bitte verbreiten Sie keine Fehlinformationen.

What do you mean, ‘already’? I raised this issue YEARS ago! And what have you actually done about it? Is DirectPlay over SMB available now? No! This isn’t misinformation!

[vdatanet 1694]

1 hour ago, Teddyknuddel said:

What do you mean, ‘already’? I raised this issue YEARS ago! And what have you actually done about it? Is DirectPlay over SMB available now? No! This isn’t misinformation!

There are real differences between the two protocols and they're worth discussing — remote access, buffering behaviour, BDMV/ISO handling, load on the server, and so on. But from a quality standpoint, both allow direct play, provided the client supports the file.

HTTP is just a transport. In direct play the server sends the exact same bytes that are on disk: no remuxing, no re-encoding, no loss. The file only gets altered when Emby decides to remux or transcode it, and that happens because the client can't handle the original container, video codec, audio track or subtitles — not because the file was requested over HTTP. If the client can play it, it plays it untouched.

[Teddyknuddel 144]

1 hour ago, vdatanet said:

HTTP is just a transport. In direct play the server sends the exact same bytes that are on disk: no remuxing, no re-encoding, no loss. The file only gets altered when Emby decides to remux or transcode it, and that happens because the client can't handle the original container, video codec, audio track or subtitles — not because the file was requested over HTTP. If the client can play it, it plays it untouched.

See my explanations here:
 

and here
 

and here
 

You can try to sugar-coat HTTP all you like – it’s not ‘direct play’. That’s simply not true. And we can go through it another 1,000 times – the stuttering and jerkiness will remain, no matter how powerful the hardware is. Of course, if I want a film without HD sound, in Full HD with a video bitrate of 6 Mb/s, then that stupid HTTP is enough.

 

[vdatanet 1694]

3 minutes ago, Teddyknuddel said:

You can try to sugar-coat HTTP all you like – it’s not ‘direct play’. That’s simply not true. And we can go through it another 1,000 times – the stuttering and jerkiness will remain, no matter how powerful the hardware is. Of course, if I want a film without HD sound, in Full HD with a video bitrate of 6 Mb/s, then that stupid HTTP is enough.

Let's separate two different claims, because they're getting mixed together.

1. "HTTP alters the file." This one is testable. Download the file from Emby over HTTP and run a checksum against the source file on disk. They match, bit for bit. Nothing is added, removed or re-encoded — it's a byte-for-byte transfer, the same as any download. And Emby itself tells you what it's doing: the dashboard says "Direct playing", "Remuxing" or "Transcoding". If it says direct play, the server isn't touching the stream, regardless of transport.

2. "It stutters at high bitrate." That's a different problem, and I don't doubt you're seeing it. But it's a buffering/throughput issue on a specific client, network path or player, not evidence that the file was modified. Stuttering means the player isn't getting bytes fast enough or isn't buffering enough of them — the bytes it does get are still the original ones.

For reference: I run Blu-ray remuxes at over 120 Mb/s with TrueHD and I've never had an issue. The TrueHD passthrough is the giveaway, actually — my receiver locks onto a genuine TrueHD bitstream. If HTTP were altering anything, that lossless track wouldn't survive intact.

So SMB may well work better on your setup, and there are good reasons to prefer it — no argument there. But "HTTP can't do direct play" is a different statement, and it isn't accurate.

[Teddyknuddel 144]

You may well be right about HTTP technically qualifying as Direct Play when the original file is delivered unchanged. But that's really beside the point I was making.

A checksum only proves that the bytes arriving at the client are identical to the bytes on the server. It does not prove that the client then buffers, demuxes, decodes and outputs those bytes equally well.

In fact, your own argument about buffering, throughput and the player confirms exactly that distinction.

My point is what happens after those identical bytes reach the client.

A good example is my Ugoos AM6B+ running Android. With the Emby Android app, I have certain media where specific HD audio tracks remain silent. The very same files and audio tracks work correctly in Kodi on the same Ugoos, under the same Android installation.

That does not happen on my Shield, so I'm not claiming that this is some universal Emby Android audio bug across every device.

But it does demonstrate the point perfectly:

Same hardware.
Same operating system.
Same file.
Same AVR.

Different playback engine — different result.

So your 120 Mb/s + TrueHD example proves that your particular material works with your particular setup. It doesn't prove that Emby's Android playback path is equivalent to Kodi's, nor that it exposes everything the underlying hardware is actually capable of.

Dolby Vision Profile 7 FEL makes that distinction even clearer. Successfully receiving the original DV7 stream over HTTP does not mean that the playback engine is actually processing the FEL. Transporting all the information and actually using all the information are two entirely different things.

And that brings us straight back to the problem of the thread starter. If the original 4K file arrives unchanged but the client nevertheless interprets or handles it incorrectly, then the fact that the transfer itself was bit-identical obviously doesn't solve the problem.

That's why I brought up direct access to the original media through something like SMB and a capable playback engine such as Kodi in the first place. It removes parts of Emby's playback path from the equation and lets software that demonstrably handles these files correctly deal with them.

So yes, you may be right about the definition of HTTP Direct Play.

But proving that HTTP can transport an unchanged file was never the interesting question.

The interesting question is what the client does with it once it gets there.

[yocker 1864]

3 minutes ago, Teddyknuddel said:

You may well be right about HTTP technically qualifying as Direct Play when the original file is delivered unchanged. But that's really beside the point I was making.

A checksum only proves that the bytes arriving at the client are identical to the bytes on the server. It does not prove that the client then buffers, demuxes, decodes and outputs those bytes equally well.

In fact, your own argument about buffering, throughput and the player confirms exactly that distinction.

My point is what happens after those identical bytes reach the client.

A good example is my Ugoos AM6B+ running Android. With the Emby Android app, I have certain media where specific HD audio tracks remain silent. The very same files and audio tracks work correctly in Kodi on the same Ugoos, under the same Android installation.

That does not happen on my Shield, so I'm not claiming that this is some universal Emby Android audio bug across every device.

But it does demonstrate the point perfectly:

Same hardware.
Same operating system.
Same file.
Same AVR.

Different playback engine — different result.

Not entirely.
Kodi might have codex available internally that Exoplayer doesn't have on the Ugoos.
Nvidia has licenses to play most formats on their Shield that the Ugoos might not have active when using Android and/or Exoplayer.
 

[Teddyknuddel 144]

That's actually much closer to the point I'm trying to make.

Whether Kodi can do it because it brings its own codec support, uses a different passthrough implementation, or can access capabilities that ExoPlayer doesn't expose is secondary.

The important part is that the same Android device is demonstrably capable of doing it with a different playback stack.

I'm not arguing that Emby should somehow force ExoPlayer to support capabilities it simply doesn't have. I'm questioning why Emby's own Android playback capabilities should ultimately be limited by ExoPlayer in the first place.

Kodi on Android doesn't use ExoPlayer as its playback engine. It has its own VideoPlayer stack and uses Android's hardware interfaces where appropriate. So if Kodi can make better use of a device's capabilities, then the limitation isn't necessarily Android or the hardware itself. It can simply be the playback stack chosen by the application.

And yes, I know the obvious answer: “Then just use an external player.”

But that isn't an equivalent solution.

As soon as playback is handed off to an external player, you lose part of the integrated Emby experience and functionality. Features such as Skip Intro and the seamless Next Episode behaviour depend on Emby controlling the playback session. So you're effectively being asked to choose:

Use Emby's internal player and accept its playback limitations, or use a more capable external player and give up Emby features.

That's exactly the compromise I'm questioning.

What I would like to see is an Emby Android player with a more capable playback stack of its own — something conceptually closer to Kodi's approach — while retaining Emby's full integration.

Then we wouldn't have to choose between maximum playback capability and the features we're paying for Emby to provide.

Maybe the real question isn't whether ExoPlayer can do everything Kodi can.

Maybe the question is why a high-end media application should permanently accept ExoPlayer's limitations as its own.