All Activity

Not your way.

A follow-up, and a retraction — mine, and it's good news for once. In my post from the 6th I wrote that putting the space back into the video range broke the other end of the round trip, and concluded from that: "no client can work around this on its own." In my last post I retracted half of it — the HTTP 400 on the segment endpoint doesn't reproduce any more. What I didn't do is re-test the conclusion that rested on it. Doing that now, it falls over completely. A client can work around this on its own, and what it gets is real HDR10. Same server, 4.9.5.0, an HDR10 MKV whose VideoRange is the "HDR 10" spelling. AudioCodec=aac, so the CODECS attribute is written (per my last post). The only variable is rewriting the parameter in the TranscodingUrl before following it: hevc-videorange=SDR,HDR10,... -> hevc-videorange=SDR,HDR%2010,... as returned with the space put back IsVideoDirect False True VIDEO-RANGE absent PQ CODECS hvc1.1.4.L126.B0,... hvc1.2.4.L150.B0,... ffprobe of init+seg0 Main / yuv420p / Main 10 / yuv420p10le / bt709 / bt709 smpte2084 / bt2020 first segment 7,690,748 bytes 12,662,628 bytes Three things I think are worth having in the thread: 1. It's genuine HDR10, not PQ tags left on an 8-bit encode — 10-bit and smpte2084 measured on the segment itself. And your own session report says IsVideoDirect=True: the video isn't being re-encoded at all, it's being copied. So the HDR path costs you a remux, not a transcode. 2. The manifest is honest in both cases. Without the rewrite it omits VIDEO-RANGE and delivers a real bt709 tone-map; with it, it declares PQ and delivers PQ. Nothing here is mislabelled. 3. So the whole HDR pipeline is already complete in 4.9.5.0, for HDR10 sources too and not only for Dolby Vision. The one thing standing between it and every client is that space being dropped when the TranscodingUrl is built. Fixing that single serialisation turns it on. One methodological note, since it cost me a wrong measurement before I caught it: this only shows up if each case gets its own PlaySessionId. If you patch the URL on a session that has already written segments, the server hands back the first transcode's files and it looks like the patch changed nothing — both segments come back byte-for-byte identical. With separate sessions the difference is immediate. To be clear, I'm not proposing that clients should do this rewrite. It's a hack against an internal parameter of yours and it only works because of the bug; if you fix the serialisation it stops being needed, and if you change the parameter's shape it would break. I'm posting it because it locates the defect precisely, and because the claim I need to withdraw was mine. The AAC-only CODECS mapping from my last post is unaffected by any of this — it's still missing with the rewrite in place. The two halves are independent.

@leshkraven The Windows app's concept for dealing with this is quite simple: Don't mess around with any Windows power-saving APIs - instead, just properly report playback operations (start, stop,, previous, next, etc.) and let everything else be handled be Window itself. What you are describing sounds like Windows assuming that there's still an ongoing (or just paused) playback operation. Do you know how to see active playback operations on Win 11? When you click on the speaker/wifi/battery symbol in the taskbar, you should also see any ongoing media playback operations. Can you see that while playing? after playback has stopped?

OK so which way is enabled in this failing example here?

OK i'll add more audio values for the next server beta build.

What is the output from netstat?

Huh? What info can I provide which I aready didn't? Do the single smb connections have individuel names? I was scanning a library, updated the mety data or watched a movie. after a while the whole NAS freezed (so no infos from this device) and I had to restart the NAS to work again. The info I provided with my first post is all I have and was done via my windows pc. Since this behaviour prevents the emby server on the shield to be of any use right now, I switched back to the WD-server again until the problem is solved. At least this is what I hoped for...

That's the right question to ask, and the answer turned out not to be in the media info at all — so let me give you that first, and then what actually decides it. MEDIA INFO (Emby web app) — "¡La novia!", the item from my earlier posts Container mkv, 19.0 GB, 21.5 Mbps overall Video 4K HDR 10 HEVC Codec hevc · Profile Main 10 · Level 150 3840x1600 (2.40:1) · 23.976 fps · 21511322 bps Bit depth 10 · Pixel format yuv420p10le VideoRange "HDR 10" · ExtendedVideoType Hdr10 · ExtendedVideoSubType Hdr10 Color space bt2020nc · transfer smpte2084 · primaries bt2020 Audio Spanish AC3 5.1 (default) · 640 kbps · 48 kHz plus Spanish E-AC-3 5.1 and English E-AC-3 5.1 But the video stream isn't what decides it. Same item, same PlaybackInfo request, transcoding forced — the only thing I change is the audio codec my transcoding profile allows: AudioCodec=aac -> CODECS="hvc1.1.4.L126.B0,mp4a.40.2" AudioCodec=mp3 -> CODECS="hvc1.1.4.L126.B0,mp4a.40.34" AudioCodec=ac3 -> attribute absent AudioCodec=eac3 -> attribute absent AudioCodec=flac / alac / opus / dts / truehd -> attribute absent AudioCodec=aac,ac3 -> attribute absent AudioCodec=aac,mp3 -> CODECS="hvc1.1.4.L126.B0,mp4a.40.2" It isn't copy versus transcode either — it's the codec the audio ends up as. Two forced audio transcodes, in opposite directions, on two MKVs. Neither source has the codec being asked for, so neither of these can be a stream copy: Cartouche (source AAC) -> out ac3 (aac -> ac3) absent ¡La novia! (source E-AC-3) -> out aac (eac3 -> aac) CODECS="hvc1.1.4.L126.B0,mp4a.40.2" So: the attribute is written if and only if the output audio codec is aac or mp3. I checked 14 items and it holds in all 14. I deliberately kept every one of them in MKV, because MP4 sources take a different decision path (TranscodeReasons=DirectPlayError on its own, rather than ContainerNotSupported,DirectPlayError) and I didn't want the container to be a second variable. Within MKV that still covers HDR10, Dolby Vision and SDR; HEVC, H.264 and VC-1; and source audio in E-AC-3, AC-3, DTS, TrueHD, MP3 and AAC. Which I think explains the whole disagreement earlier in this thread. You were right that the server populates it. I was right that I never see it. Both, because mine doesn't ask for a single audio codec — it advertises aac,ac3,alac,eac3,flac, the server picks the source AC-3 track, and the attribute disappears. I'd expect that to be true of any profile that passes AC-3 through rather than transcoding it, but I've only measured my own. That's also why "which item?" has no answer: it isn't the item. Two things, and the second matters more than the first: 1. AC-3 and E-AC-3 do have codec strings — "ac-3" and "ec-3", both in Apple's authoring specification. They just don't seem to be in the mapping. 2. More importantly: when the audio half can't be produced, the whole attribute is dropped, including the video half that was computed correctly a moment earlier. Even with an audio codec you have no string for, emitting CODECS="hvc1.2.4.L150.B0" on its own would be valid HLS, and it's all a player needs to rule the variant in or out before downloading anything — which is the whole of my original request in this thread. And the good news, because I don't think you're far from it at all. Here is the same server, same version, on a Dolby Vision source with AudioCodec=aac: #EXT-X-STREAM-INF:BANDWIDTH=31738634,AVERAGE-BANDWIDTH=26448862,VIDEO-RANGE=PQ,CODECS="hvc1.2.4.L150.B0,mp4a.40.2",RESOLUTION=3840x2160,FRAME-RATE=23.976 VIDEO-RANGE=PQ, a Main 10 codec string, fMP4 segments with #EXT-X-MAP, and both init.mp4 and the first media segment return 200. That is a fully described HDR variant, produced by 4.9.5.0 with no patching of any kind. Everything I asked for at the top of this thread is already in there. Two small things stand between that and every other file: this AAC-only mapping, and the space in "HDR 10" from my earlier post. That range name is the one difference here — "DolbyVision" has no space, so it survives the round trip through the TranscodingUrl and reaches the manifest generator intact, which is a second, independent confirmation of the serialisation bug. To be clear about why I'm still chasing this: my own app stopped needing it a few posts ago, since it now demuxes the MKV and writes its own manifest. This is the diagnosis handed over, not a request I'm still waiting on — the two attributes are what would fix this for every client that doesn't carry its own demuxer, which is nearly all of them. One correction I owe you, on my own post. I reported there that with the space put back by hand the segment endpoint returned HTTP 400 with an unhandled System.ArgumentException. I can't reproduce that today — same machine, same 4.9.5.0, same patched URL, tried with the full audio list, with eac3 and with ac3, and init.mp4 returns 200 every time. I don't know what changed, and I'd rather flag it than leave a claim of mine standing that I can't reproduce on demand. Happy to run any of this again against a build, or to test a different profile combination if it would help narrow the mapping down.

ok, thank you

That's up to the user. I've added your way as an option (native playback mode) but do not force it as a setting, because you still don't give me a way so the stream starts at the real live position instead of the beginning and some apps like the Roku do not even auto advance to the next program after the first one ended.

Hi, yes I expect that we'll be adding an option to control this. Thanks.

Since the latest update of the Android client to version 3.5.49, I suddenly see ugly gray folder icon borders around my custom media folders within my libraries. Please remove this or at least make it optional to disable! I have meticulously organized my media collection into folders and subfolders myself and invested months of fine-tuning into the user interface with my own graphics, folders, hierarchies, etc. This level of customization—especially at the file level—is the absolute only reason I decided to purchase an Emby Lifetime Subscription back then. If you now throw all of this out the window over time, all of my hard work will have been for nothing. PLEASE do not just autonomously introduce fundamental changes to the UI—especially when they are not optional but forced upon everything. This completely contradicts your own philosophy that Emby should be fully customizable by the user. Otherwise, please tell me how I can roll back this update and freeze the version status in the future. Regards, Ingmar P.S.: Since this is only on the shield client and not in the web client, i can't provide a screenshot of your folder frames. I will provide a Web scrrenshot of my medie structure instead (before the folder issue). As you can see I have organized all of my media in folders and subfolders, since the database engine based view is crap - for the provided genres are mostly wrong or at least misleading and therefore unusable. NOW on my shield I have a gray windows like folder frame around all of my own folder grafics e.g. around every single music album. which sucks!

What is your startup behavior set to in the app?

Again, my suggestion was to confirm a behavior the OP stated (which didn't make sense to me). I was not suggesting anything for playback quality.

Hi Scott, thanks for the suggestion! We are welcoming suggestions as there's always room for improvements and we don't want to miss any opportunity for getting better. Yet, in this case, I'm not quite sure what you're up to, because there's nothing like two different C# APis: There's a .NET API for developing server plugins (C# is .net language of course) And there's a REST API for accessing Emby Server via a remote connection For that REST API access, we are providing a range of ready-made implementations in various programming languages - including C#, but that's not a C# API, these are just REST API clients we provide for various languages

Are you talking about the actual poster or the treatment style? If using "cover by resolution" then this should get updated when you add a new resolution.

It is the only app that keeps my PC on all night Since I only turned emby on and didn't watch anything when running the power config command. I'll watch a film tonight and wait till it finishes and then run it in the shell again to see what it shows I have already gone through a number of troubleshooting ideas to try and solve this before creating a post.

Hi, I'm not sure I totally understand the question. Can you add an example of what you're seeing from Emby to demonstrate? Thanks.

OK then how can you be sure it's caused by the emby app?

Actually I believe everything should be getting cleaned up. When you've observed this, what were the active smb connections?

...so? Will there be a fix in the near future?

I would say that turning off internet metadata fetching in the library settings would be your best bet.

How about all the options since Emby won't post them. I searched for that exact problem. Got a hundred replies, not doing that. Just wanted to know how to fix the problem

Related? https://duckduckgo.com/?q=shield+TV+recognize+4K+playback+content&ia=web https://www.howtogeek.com/251204/how-to-enable-4k-playback-on-the-nvidia-shield-android-tv/ Maybe everything needs settings, just right, so they can all dance together. Also saw metnion of HDCP 2.2-compatible port and 4K HDMI cables are needed to allow 4K to arrive and play on the TV. Is it possible one of those is not right?

That is the strange thing, it always shows none PS C:\WINDOWS\system32> powercfg /requests DISPLAY: None. SYSTEM: None. AWAYMODE: None. EXECUTION: None. PERFBOOST: None. ACTIVELOCKSCREEN: None. PS C:\WINDOWS\system32>