All Activity

Hello, what else can I try?

I understand, I'm just a silly nerd in a basement

I'm not a fan of jellyfin but I do like it more than plex. For me I will use emby and pay monthly indefinitely I like it more than other platforms it just keeps getting better with better support more people on the forums so yeah, better community here. I do tinker with jellyfin css and silly stuff like take a live link from a few movies and throw it on tivimate as an m3u just crap like that. But emby is what I support and will continue to support.

Well put diplomatically. So I was compelled to look up this THRASHY girl... ah now it makes sense... Square pegs and round holes... I tried that once. Didn't work sad to say.

Forgive me if I'm misunderstanding how the setting works. I assume it works by looking at pixel width and not total pixels, but I could be wrong. The problem, in short: When a 4k video is a few pixels narrower than standard 4k, the setting seems to identify it as the next smaller resolution (hd instead of 4k). The problem, longer explanation: When match video resolution is enabled and a video that has a horizontal resolution less than a particular threshold such as 3840 for 4k or 1920 for hd (maybe 3838, or 1918 for example, sometimes due to having a couple pixels trimmed off the edges horizontally to crop out minuscule black bars, or more noticeably when the aspect ratio is more square), match video resolution seems to identify this as something smaller than the intended resolution of 4k or hd, and matches the video resolution to the next smallest resolution. So a 4k movie is being displayed at 1080, and any scaling the tv is doing is doing it unnecessarily or inaccurately for the source resolution. Proposed solution: I assume the way the setting works is by telling emby "any horizontal pixel width less than x should be identified as y". And instead of setting that pixel width to the normal 3840 for 4k, change it to something slightly smaller like 3820. (Or if it uses total pixels, then the total pixels could be adjusted accordingly.)

How do i do that? Im really not very techy

Agreed.

@JordanThe green tint is caused by the server transcoding/converting the stream, disabling transcoding and container changing permissions for the user is a good temporary fix. Often times the transcode is due to TrueHD audio being selected for the stream. At the moment the Emby Server unnecessarily transcodes TrueHD audio even though the Apple TV is able to convert it client side. The server side conversion is causing the Dolby Vision colors to be incorrect. I've made @Lukeaware of this in a recent post.

Stop sailing the high seas, and conform to the naming conversions Emby needs.

Hi, no updates yet but we plan to make the top tabs configurable in future updates. Thanks.

Thanks for sharing.

Hi, we'll take a look at this. Thanks for reporting.

Hi, what version number are you on now?

Still nothing. Exact same problem years later.

@LukeThis has been going on for so insanely long now. You responded to posts in 2024 about the EXACT same issue that 'you were taking a look at it'. Can you please just be honest.

Am I making a simple folder structure mistake that I am just too blind to see? I honestly don't recall this ever being an issue until 2 days ago. Since I'm 99% Kodi user that has it's own addons, I guess I may have never seen this. Any guidance would be appreciated before I embark on who directory structure redo. I suppose I could wait till the weekend and peel off a few shows into a separate library for testing. /taking grandma nap.

I'm experiencing what appears to be the same issue on a Synology NAS and wanted to share my findings in case they help. Environment Synology DS1819+ DSM 7.3.2-86009 32 GB RAM Emby Server 4.9.5.0 (Package Center installation) .NET 8 runtime bundled with Emby The problem only started recently. Prior to that, this server had been running reliably for a long time. Symptoms After a restart, Emby starts normally using approximately 350-400 MB RSS. Throughout the day it remains very stable, even under heavy load. I tested: Three simultaneous 4K streams A full manual library scan while streaming During those tests, Emby's RSS never exceeded approximately 850 MB. The interesting part is that the problem consistently starts around midnight. At approximately midnight, Emby's memory usage begins increasing in large steps. From that point on, the resident memory continues growing throughout the night until the server eventually runs out of memory and the Linux OOM killer terminates the Emby process. On the night I monitored it, I observed approximately: 0.4 GB 1.3 GB 4.3 GB 4.8 GB 7.2 GB eventually peaking at 28.6 GB RSS The growth appears to occur in roughly 30-minute intervals. Suggesting a process starting at midnight being triggered again and again every 30 minutes, eating up more and more memory every time until it crashes. During this entire period the process is mostly idle: CPU around 4% approximately 20-21 threads process state is generally "sleeping" So, it looks like something is simply eating up the memory, but not doing anything meaningful. Kernel logs The Linux kernel consistently reports Emby using approximately 25 GB of anonymous RSS immediately before it is killed. Example: Out of memory: Kill process 30784 (EmbyServer) Killed process 30784 (EmbyServer) anon-rss:25216920kB Monitoring To investigate, I wrote a script that records Emby's memory every minute and ingested the data into Splunk. The graph clearly shows: Emby's RSS increasing in large steps beginning around midnight. Total system memory usage following Emby's growth almost exactly. Memory continuing to increase throughout the night until the OOM event. Jumps occur every 30 minutes, increasing about 3GB every time, until it crashes. You see the moment it crashes, the sudden deallocation of all that memory. I only realized it was down about an hour later and then I brought it back manually. When it came back, memory usage returns to a constant of 350-450MB and it's not increasing at this moment. Debug logging With debug logging enabled, I noticed repeated library validation messages approximately every 30 minutes: ValidatePhysicalRoots ValidateTopLibraryFolders The timing appears to correlate with the memory increases, although I can't yet say whether those operations are the cause or simply occur at the same time. Plugin observation After reading Luke's recommendation in this thread, I checked my installed plugins. Of the plugins mentioned, the only one I had installed was Statistics 3.4.2.0. So i just removed it and I'll monitor what happens at midnight now. My logs also have many 404 errors from the TMDB plugin at the 30 minute intervals. This plugin was was not mentioned by @Lukebut it might play a part in this issue. I also realized that I installed the Statistics plugin relatively recently, which roughly coincides with when I first started noticing this problem. I can't say whether it's the cause, but as my next step I've removed the Statistics plugin and will monitor tonight's behavior to see whether the overnight memory growth still occurs. If anyone would like them, I have: minute-by-minute RSS history system memory history debug logs kernel OOM logs graphs showing the complete overnight memory progression Script i devised to grab the Emby statistics minute by minute to be ingested by Splunk Hopefully this helps determine whether we're seeing the same underlying issue.

I've done this and will share with you via the link you DM'd me.

There ain't. You can only do it in a per-item basis as @pwhodgessaid. You can lend your support here And for future instances:

I've been using Emby since way back in the MediaBrowser days, so I am unfamiliar with THRASH and who she is? She TRASHY? Never been viable, so common in this space... (such blanket statements being tossed around.) Of course why follow the Software Providers requirements at all? (your words, not mine as bolded above) and just do your own thing. They gave you the options to a tag after the filename and you choose not to use them. Again, so strange why people don't follow what the software vendor REQUIRES them to do then complain. I'm going to bed before football starts. Thread on mute.

Is there a reason this isn't just being offered as a .dll I can drop into my plugins folder, as with all other Emby plugins? I don't know my way around building things or whatever. I had the old backups plugin, so I have a section like this in the NFO file for each episode: <markers> <introstart>771144278</introstart> <introend>875621889</introend> <creditstart>0</creditstart> </markers> Will this work to restore them?

The one i selct to get the subs back under playing is: Playback Correction. If I use this, the sub are showing as the should. If I remember correctly it was more options on the server side regards for subs. Like "Force burn in", but this could be an error in my head But still, I think my shield played this before, so I don't understand.

I don't know of a general purge; but you can, slightly tediously, right-click (or equivalent) each entry you no longer want and select "Remove from Continue Watching" from that menu. Paul

What I would do just to test is remove the limit and see if others start streaming from the same account. Sorry it's all I can think of that could at least indicate what the problem might be.

Emby Insights gives admins a quick snapshot of key server stats right on the home screen, browser only ! Playback Reporting is currently only required for usage and playback statistics — not for the general server and media facts. Currently in beta, available on GitHub --> ( https://github.com/mrt187/EmbyInsights ) Works with both the stable and beta Emby Server versions -- -- *This plugin was built with AI — feel free to check the code for safety, and use at your own risk.