All Activity

I have upgraded to 4.9.5.0 for now, we'll see. I also went back through my Grafana monitoring and found memory usage was higher than I thought with 4.8.11(25GB after 2 months), but that happened much slower and is still half of what I have seen 4.9+ consume. For reference, here is a Grafana screenshot showing memory usage for previous versions across the last year. Apologies that the version numbers are "out of order" on the legend, but you can see on the left-hand side of the graph that 4.8.11.0 consume 24GB of RAM slowly, after 2 months. The light colored blue after that red one is 4.9.1.90 - memory consumption instantly shot up aggressively. It only took 1 week of running on 4.9.1.90 to consume as much memory (21GB) as 4.8.11.0 would consume after running for a month+.. 49.3GB after 2 months of running 4.9.3.0 (green line in the middle) - same pattern with the blue line starting in March of 2026 - 4.9.3.0 consumes 49GB of RAM after 2 months. And attached is also a more "zoomed in" view of current memory consumption trends on 4.9.3.0.

I am not opposed to giving it another shot. I feel like I have but now I can't recall. I will upgrade to 4.9.5 to see. I also found this thread with a lot more posts, didn't read everything, only the last few pages, but not sure I saw any resolution there either. https://emby.media/community/topic/142886-emby-ram-maxing-out/page/18/

Hi, have you updated to Emby Server 4.9.5? Has that helped?

This did not seem to be the case before 4.9.3.0.. I have had a consistently large library for a long time and only recently started experiencing this. Previously my Emby Server would run for literal months and never go above 6-10GB of RAM. 4.9.3.0 has been running for 2.5 weeks and is consuming 25GB right now. I don't really think the solution should be "slower intervals for media scans" or "weekly server restarts" when this is clearly a regression and should be fixed?

Well what's odd is that all 3 artist IDs are the same between the single-track artist page and the "correct" artist page (MD, AudioDB, Discogs). I did not see any spelling differences on the album tags. On the file itself, there are no artist IDs (only MUSICBRAINZ_ALBUMID). Running the files through Picard, saving them, and forcing a rescan in Emby does not fix the incorrectly identified artists in the search results.

Title Dolby Vision Profile 5 sources transcode to green/purple: Emby inserts no tonemap for P5, while CUDA DOVI reshaping (jellyfin-ffmpeg tonemap_cuda) fixes it on identical hardware Body Environment Emby Server 4.9.5.0 (stable), Docker on a QNAP NAS (Premiere active) NVIDIA GTX 1050 Ti (Pascal, CC 6.1), driver 575.x, NVENC/NVDEC healthy Hardware tone mapping enabled and working for other HDR types Symptom Any Dolby Vision Profile 5 source (dv_profile: 5, dv_bl_signal_compatibility_id: 0 — base layer IPTPQc2, no HDR10/SDR compatibility layer) transcoded to 1080p SDR produces a fully green/magenta picture. Playback, speed and subtitles are fine — only color is wrong. Control group, same day, same GPU: HDR10, DV Profile 8.1 and Profile 7.6 all tone-map correctly (tonemap_cuda=hable appears in the ffmpeg-transcode logs). Root cause observed For P5 sources Emby's graph builder inserts no tonemap filter at all (verified from the ffmpeg-transcode logs). The IPT (ICtCp) data is then scaled and encoded as if it were ordinary YCbCr, hence green/purple. What we tried that did NOT work (all verified empirically, same frame) EnableSoftwareToneMapping=true: byte-identical filter graph and byte-identical output frames (md5) for P5 — zero effect. Emby's built-in supertonemap filter on a P5 frame: pure black output. libplacebo/Vulkan route (forum topic 144597): not viable in our NVIDIA Docker setup — no Vulkan ICD manifests, runc container with manually bound /dev/nvidia* (no nvidia-container-runtime), and no NVIDIA driver libraries inside the GPU image. What DOES work on the exact same hardware and frame jellyfin-ffmpeg 8.1.2 tonemap_cuda: colors fully correct. DOVI reshaping for P5 is baked into the CUDA kernel (jellyfin-ffmpeg#151, never upstreamed to FFmpeg). tonemapx (CPU software route): also correct. The blocker is server-side graph generation An ffmpeg binary with P5 reshaping is necessary but not sufficient: Emby decides the filter graph, and for P5 it decides on no tonemap. Swapping in jellyfin-ffmpeg wholesale is not viable for us either, because Emby's ffmpeg is a fork with private filters (e.g. supertonemap) that our working HDR10 / P8.1 / P7.6 paths depend on. Request Add Dolby Vision Profile 5 (IPTPQc2) reshaping to Emby's transcoding pipeline — ideally the CUDA route, since the kernel work is already proven by jellyfin-ffmpeg#151, with a CPU fallback. Failing that, a supported/documented escape hatch to hand P5 transcodes to a custom ffmpeg without disturbing other codec paths. Clarification: does the 4.10.0.24/25 beta changelog item Fix Hardware Transcoding for HDR Video when Tone Mapping is enabled affect DV Profile 5 at all? Offer Happy to beta-test on the affected hardware. We have a repeatable one-frame probe (a known P5 file, frame at 420s, compared against reference frames produced by the working tonemap_cuda pipeline), so any candidate build can be verified in about a minute. Impact note Direct play on DV-capable clients is unaffected; this only hits the transcode path (remote/cellular viewing). About 30 items / 10 titles in our library are affected.

HI ,it works just fine, but it requires a library scan after changing.

It looks like renaming just part 2 using that naming standard: (i.e. Chainsaw Man - The Compilation Part 2 (2025) [tmdb=1544707]). It does indeed unstack the videos. Thanks for your help RanmaCanada! I will have to say that I think it's a bug, though. The library option of "Enable multi-part items" doesn't seem to work as expected.

I was in the same situation when I first started using IPTV with media servers. It can be a little confusing at first, especially if you’re not very familiar with the setup. I ended up using Xuper TV separately for streaming because it was much simpler for me and didn’t require a complicated setup.

Have them in separate folders for starters and name their folders and files properly as per the naming guidelines Name (Year) [tmdb=xxxx] Chainsaw Man - The Compilation Part 1 (2025) [tmdb=1544513] Chainsaw Man - The Compilation Part 2 (2025) [tmdb=1544707] This should fix it.

OK we'll take a look at it. Thanks.

Which help text? On this forum or in the emby library settings?

HI, did you also read the help text at the top of the dialog?

Apologies in advance for the AI prepared tarball but I have been trying to work with Claude to understand the root issues for the last 2 months and it has all the memory stored! @LukePlease see the attached tarball for multiple logs. It contains a mixed usage of software encoding + hardware accelerated encoding. Let me know if you require anything else! NOTE: Tarball is 3.9MB and gets extracted to around 45MB and contains 10 text files. emby-stuck-sessions-logs.tar.gz

Yes. The first thing I did was turn off "Enable multi-part items". It still didn't change it's behavior.

Hi there, have you explored the options on the library?

Hi, we are working on improving this. Thanks.

Hi, what version number of our standard android app did you try?

Just gathering these now for you @Luke. The post will be updated shortly!

Hello pierce1921, ** This is an auto reply ** Please wait for someone from staff support or our members to reply to you. It's recommended to provide more info, as it explain in this thread: Thank you. Emby Team

Does anyone know how to prevent emby from automatically joining/stacking two movies that have the names Part 1 and Part 2 in their title? I have two movies: "Chainsaw Man - The Compilation Part 1 (2025)" and "Chainsaw Man - The Compilation Part 2 (2025)" which have two different TMDB ids keep showing up as "Chainsaw Man - The Compilation Part 1 (2025)". When I move Part 1 out of the media folder it then picks up Part 2. But, Part 2 disappears when I put Part 1 back in place. I don't have any other media that I would want to auto join/stack, so I would prefer to turn that feature off completely. I am running emby version 4.9.5.0 on Centos 10.

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

Will do

Hello! I have been experiencing some zombie sessions (currently playing sessions that get stuck on paused OR once reaching the end don't close the session) occurring quite frequently. I've done some logging to determine what the cause is and it seems to be related to subtitles? I am wondering if anyone has experienced something similar. Normally this wouldn't be a problem with unlimited sessions but because I share with a few friends and my home internet is quite bad up, I limit people to 2 streams MAX to avoid my internet becoming affected. Some of the zombie sessions symptoms cause: My CPU getting pegged at 100% until I restart Emby which causes other services to be affected. Session limits are being hit and users cannot play media as one of the zombie sessions are taking up one of their simultaneous slots. Transcode temp directories are not being emptied so it endlessly grows upwards of multiple GBs. Some of the steps I've taken to try and fix this are: Restarting Emby (clear winner, sometimes those zombies sessions survive a restart). Restarting the server to clear any ffmpeg processes (often nuclear option, rarely happens but most of my friends use subtitles). Writing a grim reaper script that detects these sessions and attempt to clear the ffmpeg process + clean up any related transcoding folders. Moving my Emby server onto a separate VM so that the storage node is not affected. I guess this kinda turns into a feature request but, is it possible to have an API endpoint that can properly kill sessions and action any fast follows? For the developers of Emby, let me know if you need any troubleshooting logs. Is there any ffmpeg patches that are applied on beta that are not in stable? I don't remember running into this issue on stable! Regards, Gabe.

are you using the latest version? it was only fixed in newer versions this year. softworkz is also working on a trailer update for a future release.