All Activity

You'll see this in an upcoming Roku app update.

Same issue on android client.

Hi, is any emby server log file generated? How to Report a Problem

It failed to correct the name but did record the entire show.

You don't have any in the catalog targeting higher than that, do you?

Hi, this is resolved for the next update to the app. Thanks.

Hi, with you have podman and podman-compose, create this compose.yaml: services: emby: image: docker.io/emby/embyserver@sha256:3aafff933d3f28d23ed0bc201022abe71c0aa80deb17177566c726b9bbc686c6 container_name: embyserver network_mode: host environment: - UID=1000 - GID=100 - GIDLIST=100 - NVIDIA_VISIBLE_DEVICES=all - NVIDIA_DRIVER_CAPABILITIES=compute,video,utility volumes: - ./emby/data:/config:z - /mnt/external_disk:/mnt/:rw devices: - nvidia.com/gpu=all restart: unless-stopped I has runnning this compose, for a long time (remember this compose in volumes setup for my homelab, in you case check volume setting).

*SHOULD!*

Thanks for the reply. Yep, in the old app it had the functionality I'm after. I humbly ask for a return to those simpler times but since they're going for a universal Android experience, I might be SOL.

Don't know if it helps, or is relevant, but in the new app (non ATV), you get the fast forward going and release, then every time you press and release FF it goes faster. In the old app you hold it down and it gradually accelerates by itself. Think thats right, can't test on Shield at the mo.

But plugins should target .Net Standard 2.0 and that is only C# 7.3.

I needed some new user avatar images since my last ones were getting tired and dated. I had ChatGPT make the background and I then used Photopea to add the names. Attached is the png as well as the psd template. Yes, I created both colors for each user and then changed their avatar to get these screenshots! Emby users avatar background.psd

Been away from Emby for a while and getting back into it and downloaded the Emby for Android app (not the TV version) and noticed that when I held down the right button on my remote (using an Nvidia Shield) to fast forward, the video I was watching continued to play back at a normal speed but the little playback indicator continued across the screen at a decent pace even though I let up on the right navigation button. (Bug ?) I know I can tap the right navigation button and it will jump ahead whatever I set (10 seconds, 30 seconds, etc) with every tap but I want it to fast forward at an incrementing speed for as long as I hold down the fast forward button. Or if I'm holding the right navigation button down, I'd like it to keep fast forwarding exponentially until I let up and when I do let up, play resumes at that spot automatically. Is that doable? (Or can the app do that now and I don't have something configured correctly?) I think what I'm referring to is similar to this post:

Please nobody tell my mom about this. Whew that was close.

Since the recent-ish changes to the pin pop up behavior, I've discovered that when the pin screen pops up on my Shield, I can just press the back button twice to skip entering the pin altogether and get back to Emby use as the currently logged in user. It may also be by-passable in other scenarios, but the specific one that led to me noticing is when I've left playback paused, leave the app, and come back to Emby later. Emby will resume play back and otherwise be responsive to user input, then decide to pop up the pin screen a few seconds later. Pressing back at this point backs out of the pin screen and to the select user screen (I think), then a second press exits back to Emby usage as the already logged in user with the pin protection.

Everything still works just fine - it sits in a tighly controlled network zone so security is not an issue. There is nothing in the newer versions that I have need for - so unless there is a good reason to upgrade, my view is leave it alone...

Seems to be working well for me so far. A lot of missing shows, but I imagine it will get better over time. If the API limit is 500/day, why is the default API lookup per run 10000? Surely this should be way lower?

Thanks!

Hi, it doesn't matter.

Sorry, late to the party! It is Dolby Vision. I have some DV movies and Emby will not tonemap unless I force a transcode of the video. You can verify this with the "Stats for Nerds" option while playing the video. The only way I can get it to tonemap is to do playback correction twice: once for transcoding audio and a second time to transcode the video. Once it starts transcoding the video, it will tonemap properly. You can verify that it is working by bringing up Stats for Nerds. It will say tonemapping.

OK yes we are continuing to work on improving it. Thanks.

The audio mapping is in the stable build — thank you. Same table as before, now on 4.10.0.40 and against my real library instead of the synthetic file: requested CODECS attribute aac "hvc1.1.4.L126.B0,mp4a.40.2" mp3 "hvc1.1.4.L126.B0,mp4a.40.34" ac3 "hvc1.1.4.L126.B0,ac-3" eac3 "hvc1.1.4.L126.B0,ec-3" flac "hvc1.1.4.L126.B0,fLaC" opus "hvc1.1.4.L126.B0,opus" dts "hvc1.1.4.L126.B0,ac-3" alac attribute absent truehd attribute absent aac,ac3,alac,eac3,flac "hvc1.1.4.L126.B0,ac-3" <- my app's actual profile alac and truehd still drop the whole attribute, video half included, but the row that mattered to me is the last one and it now works for anyone who updates. The reason I'm posting, though, is two things I ran into while measuring that — and both are worth more to you than to me. 1) YOUR SERVER ALREADY SERVES DOLBY VISION TO AN APPLE TV WITHOUT TRANSCODING IT What stopped it here was what my client was asking for. My app declared only SDR ranges to Emby, on purpose, because the manifest carried no VIDEO-RANGE and a player that doesn't know the range won't switch the TV into HDR. The reason it carried none is the "HDR 10" space round-trip I reported earlier in this thread — but "DolbyVision" has no space, so it survives it. Declaring it changes the answer on the same file: hevc VideoRange=SDR|DOVIWithSDR CODECS="hvc1.1.4.L126.B0,ac-3" (Main, 8-bit, tone-mapped) hevc VideoRange=SDR|DOVIWithSDR|DolbyVision VIDEO-RANGE=PQ, CODECS="hvc1.2.4.L150.B0,ac-3" There is a second half, and it cost me longer than the first: with the range accepted but a TS/h264 transcoding profile listed first, the server still re-encoded. Your StreamBuilder ranks a profile that can copy above one that can't, so the fMP4/HEVC profile has to be allowed to win — on my side that meant no longer excluding HDR sources from the "prefer copy" decision I make before asking. With both halves in place, here is what the server does with a 3840x1606 DV Profile 8.1 file and an E-AC-3 5.1 track, straight from your own ffmpeg log: -c:v:0 copy -c:a:0 copy -hls_segment_type fmp4 -vtag hvc1 Stream #0:0 -> #0:0 (copy) hevc (Main 10) (hvc1), yuv420p10le, bt2020nc/bt2020/smpte2084, 3840x1606 Stream #0:1 -> #0:1 (copy) eac3 5.1, 640 kb/s DOVI configuration record: version: 1.0, profile: 8, level: 6, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1 No encoder, no tone-map, audio passed through, the DOVI RPU intact inside the fMP4 segments, and the TV lights up in HDR. Before the change, the same file on the same server went through tonemap_opencl=reinhard into h264_qsv at 1920x770. The only real work left is the subtitle tracks going to WebVTT. I'm spelling out both halves rather than just saying "it works now" because this is a client-side decision, not a server one, and I know other Apple TV client developers read this thread. On my server I still see the official tvOS app transcode this same file, and from the server's side the entire difference is those two things: a range name in the device profile, and letting the copy-capable transcoding profile win the tie. Whoever finds it useful, it's yours — it took me a day to find the second half and there's no reason for anyone else to spend it. 2) AND WHILE I'M AT IT: ON AN APPLE TV, MP4 IS BETTER SERVED AS HLS THAN AS DIRECT PLAY This one has nothing to do with HDR and I've never posted it here. Direct play works with MP4 — the native player will happily take an MP4 with HEVC Main 10 and AC-3 straight off the server. What it won't do is keep the buffer fed. Measured on an Apple TV 4K, same box, same LAN, same files, with an on-screen buffer readout: 67 Mbps remux, direct play starts ~10 s, drains to 1-2 s, never recovers: it stalls for good 15 Mbps file, direct play 5 s after a minute, 1 s after two, but it claws its way back either of them over HLS 50-60 s of buffer, steady for the whole film The interesting part is that the bleed is proportional, not a threshold: the progressive path delivers about 92% of what playback consumes, so you lose roughly 5 s of buffer for every minute played. The bitrate only decides how long you have before you hit zero — there is no safe "max direct play bitrate", just a slower death. It isn't decoding (an Apple TV 4K does HEVC Main 10 to L5.1 without breaking a sweat) and it isn't the network: a Mac direct-plays the same files over the same LAN with 32-52 s of buffer and no stalls. It's AVFoundation's progressive HTTP path on tvOS. Two things that look like fixes and aren't: preferredForwardBufferDuration (ignored on progressive assets unless you also set automaticallyWaitsToMinimizeStalling = false, and even then it only delays the drain) and seeking to force a re-fill (it drains again from scratch). What fixes it is serving the same file over HLS, and it costs the server nothing: -c:v copy, same bits, segmented with a manifest in front. That's the path the player is tuned for, and it's what Apple's authoring spec for long-form content is written around. It's also why players that bundle their own engine never hit any of this — they are not on that path to begin with. My own client does exactly that: it declines direct play for video entirely and asks for HLS, MP4 sources included. That is a device-profile decision, so it may be one worth revisiting in yours. Two things still on your side, and neither is urgent: - The "HDR 10" space round-trip is unchanged in 4.10.0.40, so HDR10 sources still tone-map. Dolby Vision only gets through because its name happens to have no space in it. - For the player to switch into Dolby Vision proper rather than HDR10, the variant would also need SUPPLEMENTAL-CODECS="dvh1.08.06/db1p" alongside VIDEO-RANGE=PQ, which is what Apple's HLS authoring spec asks for. With Profile 8.1 the base layer is HDR10-compatible and the picture is right either way, so this is the smaller of the two. Happy to keep running the table against future builds.

Well done, both of those bugs have been squashed. However, not sure how the badges are being scaled, as episode images now (with the new setting) get huge badge on Extra Large (while Poster badges retained their size as previously with the same setting); maybe thumb-type image badges should get their own size picker? vs. previously: Poster:

I have deleted the second emby source. It is now set to Local Over the Air Broadcast (which is what is was set to at first) currently recording. Server log will be sent via DM. I will record Radio 1 Dance Party with Danny Howard and let it finish normally and see what happens to the filename. Tuner Channel 700 Channel Number.

yes thanks. that was what i needed.