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 1698]

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 1698]

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 1866]

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.

[Teddyknuddel 144]

I'm not talking about whether Emby's HTTP stream qualifies as “Direct Play”. I'm talking about direct file access, where the player opens the original media file directly from the network share instead of receiving it through Emby's HTTP playback pipeline.

[yocker 1866]

2 minutes ago, Teddyknuddel said:

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.

Because it's available on all Android devices.
Supplying another player might also cause other unforeseen problems like audio passthrough not working.
IMO. Exoplayer is not perfect but it does a more than fine work. 

Android it self does not (at least natively) support FEL playback anyway.
So using another player would not help anyway and you would need a completely different operating system to fix that.

Yes, the Ugoos might have the capability for more but have the developers of it made sure that their version of Android supports it instead of only CoreElec?
No matter the hardware it still needs the software used to have support for it.
For example, try and get Dolby Vision to work on a Linux machine even though it's hardware is more than capable of it.

Buffering in Emby when viewing remotely is most likely a connection problem.
I can easily watch remux files remotely from my server without any buffering or stutter.
 

[vdatanet 1698]

6 minutes ago, Teddyknuddel said:

I'm not talking about whether Emby's HTTP stream qualifies as “Direct Play”. I'm talking about direct file access, where the player opens the original media file directly from the network share instead of receiving it through Emby's HTTP playback pipeline.

Fair enough — direct file access and Direct Play are different concepts, and I'm happy to use the terms properly. Direct file access means the player opens the file from the share itself and handles its own I/O, rather than pulling it through the server's playback pipeline. That's a real distinction and it has genuine advantages: the server is out of the path entirely, the player does its own buffering and seeking, and things like BDMV or ISO structures with menus work properly.

But that's an architecture argument, not a quality one. Your earlier point was that HTTP alters the file and can't do direct play — that's the claim I was answering. In both cases the player receives the same bytes; what differs is who reads them off the disk and how they're buffered. So if direct file access works better on your hardware and player, that's a perfectly good reason to use it. It just isn't a difference in what ends up on screen or coming out of the receiver.

[Teddyknuddel 144]

7 minutes ago, yocker said:

Because it's available on all Android devices.
Supplying another player might also cause other unforeseen problems like audio passthrough not working.
IMO. Exoplayer is not perfect but it does a more than fine work. 

Android it self does not (at least natively) support FEL playback anyway.
So using another player would not help anyway and you would need a completely different operating system to fix that.

Yes, the Ugoos might have the capability for more but have the developers of it made sure that their version of Android supports it instead of only CoreElec?
No matter the hardware it still needs the software used to have support for it.
For example, try and get Dolby Vision to work on a Linux machine even though it's hardware is more than capable of it.

Buffering in Emby when viewing remotely is most likely a connection problem.
I can easily watch remux files remotely from my server without any buffering or stutter.
 

You're right about FEL. At the moment, proper FEL playback on these Ugoos devices is a CoreELEC solution, not something available under their stock Android implementation.

I do think it would technically be possible under Android with the right hardware, drivers and Dolby implementation, but that would likely involve licensing as well as considerable development effort.

But FEL is really a different subject and wasn't the point I was trying to make here. I probably shouldn't have brought it into this discussion in the first place.

 

6 minutes ago, vdatanet said:

Fair enough — direct file access and Direct Play are different concepts, and I'm happy to use the terms properly. Direct file access means the player opens the file from the share itself and handles its own I/O, rather than pulling it through the server's playback pipeline. That's a real distinction and it has genuine advantages: the server is out of the path entirely, the player does its own buffering and seeking, and things like BDMV or ISO structures with menus work properly.

But that's an architecture argument, not a quality one. Your earlier point was that HTTP alters the file and can't do direct play — that's the claim I was answering. In both cases the player receives the same bytes; what differs is who reads them off the disk and how they're buffered. So if direct file access works better on your hardware and player, that's a perfectly good reason to use it. It just isn't a difference in what ends up on screen or coming out of the receiver.

Yes, that's a fair distinction, and I think we've actually reached agreement on that part.

My earlier wording about HTTP altering the file was incorrect. If Emby sends the original file byte-for-byte unchanged, then it is Direct Play regardless of whether the transport is HTTP.

What I was really referring to was direct file access, and you've described the distinction pretty much exactly as I mean it: the server is removed from the media data path and the player handles its own I/O, buffering and seeking directly from the share.

I'm not claiming that this inherently produces better picture or sound quality. If the same bytes reach the decoder, they're the same bytes. My point is that it gives the player more direct control over the playback path and can therefore be advantageous depending on the player, device and media involved.

So on that point, I think we're actually on the same page now

[vdatanet 1698]

8 minutes ago, Teddyknuddel said:

Yes, that's a fair distinction, and I think we've actually reached agreement on that part.

My earlier wording about HTTP altering the file was incorrect. If Emby sends the original file byte-for-byte unchanged, then it is Direct Play regardless of whether the transport is HTTP.

What I was really referring to was direct file access, and you've described the distinction pretty much exactly as I mean it: the server is removed from the media data path and the player handles its own I/O, buffering and seeking directly from the share.

I'm not claiming that this inherently produces better picture or sound quality. If the same bytes reach the decoder, they're the same bytes. My point is that it gives the player more direct control over the playback path and can therefore be advantageous depending on the player, device and media involved.

So on that point, I think we're actually on the same page now

One more thought, and I think this is where we actually agree.

Emby does support the concept — libraries have a shared network folder field precisely so a client can be pointed at the original path, and that's what Kodi and a few other players use. But the number of clients that can actually make use of it is small. The browser can't. Chromecast can't. Samsung and LG TV apps have no SMB stack and no way to store share credentials. iOS is heavily restricted. And none of it works away from home without a VPN. So you end up with a feature that only pays off for a specific setup: a player capable of network file I/O, on a wired LAN, with the share reachable.

That's not a knock on it — for that setup it's clearly the better path, and your results show it. It just explains why it stays a niche option rather than something the apps are built around. Developers are going to put their effort into the path that works for the other 95% of clients, and keep direct file access as the hook it already is for the players that can use it.

[Teddyknuddel 144]

Yes, I think we actually do agree on this now.

And that's exactly how I'm using Emby with Kodi/CoreELEC: Emby manages the library and metadata, while Kodi accesses the original files directly through the shared network paths.

I also understand why Emby can't build its entire client architecture around direct file access. For browsers, Chromecast, Smart TV apps and many mobile devices, HTTP is obviously the practical and often the only viable solution.

My point was never that HTTP should be removed or replaced for those clients. I would simply like direct file access to remain a first-class option on platforms where it makes sense and where the client is capable of using it.

For my setup, that's clearly the better playback path. For somebody else's setup, HTTP Direct Play may be the better choice.

So yes — I think we've pretty much beaten this particular horse to death.