All Activity

@sa2000I have sent you my logs via DM, and I also sent you my script that's collecting the statistics. I have been scanning every 30 minutes since I installed emby years ago and never had any issues. That's mostly because the hardware is powerful and largely underutilized. I have 32G of ram and until this problem started emby had never used more than 1GB RAM even under heavy stress (serving simultaneous 4K videos to all four KODIs in the house while scanning at the same time). This points to something new, introduced by a plugin or one of the latest updates, as I keep my emby version up to date as much as I can. Thanks for looking at my logs! I hope they're useful and lead to a solution of this issue to us all!

But I want FLAC to be played by default. I don't want to have to convert the format every time just because of a browser.

See attachment, one folder automatically plugged in an image while the other did not.

What was the solution?

Hi that’s odd. The browser must be reporting that it supports it. The next release will have a section in settings to force transcoding of certain formats so you can use that.

The date issues for non-US users also bothered me. Air Date Fixer is created from the ground up. The Alpha plugin is about 97% done, just a few more tweaks.

Description: I found what appears to be an issue with codec detection or playback profile matching in Emby Server 4.9.5.0. Environment: Emby Server: 4.9.5.0 Platform: ReadyNAS (Linux) Client: Emby Web Browser: Sony Vewd Browser (OMI) User-Agent: Mozilla/5.0 (Linux; Android 12; BRAVIA 4K VH22) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.120 Safari/537.36 OMI/4.25.1.92.StableAVB_Sony.1 Problem: The Sony Vewd browser is unable to play FLAC audio. However, Emby does not transcode FLAC to AAC (or another supported codec). Instead, it serves the original FLAC file directly, causing playback to fail. Audio transcoding is enabled for the user. Expected behavior: Since the browser does not support FLAC playback, Emby should automatically transcode the audio to AAC (or another supported format). Actual behavior: The playback request is made through the UniversalAudioService with: AudioCodec=aac but the server responds with: Content-Type: audio/flac The original FLAC stream is sent instead of a transcoded AAC stream. Relevant log excerpts: User policy: EnableAudioPlaybackTranscoding: True GET /emby/Audio/.../universal ... AudioCodec=aac Response: Content-Type: audio/flac Additional information: The issue only occurs with the Sony Vewd browser. Other clients (Android TV app, desktop browsers, etc.) work as expected. It appears that Emby incorrectly assumes that the Vewd browser supports FLAC playback, or the browser's playback profile incorrectly advertises FLAC support. Could this be a bug in the Vewd browser device profile or codec detection logic? embyserver_sanitized.txt

the order you use to display them inside a collection..... and even if let's say you dont want to bother with the order just something like A collection you started has Unwatched elements and so you just display directly the collection and up to the user when he sees that to say "oh 'im missing a "Scream movie" i havent seen then click and he will see the elements within that collection and launch the one he wants if he misses more than one but its actually sad to have a media center and forgetting about some Collections that have a new movie released in it or that we havent finished..... and as the actual home screen continue watching we can hide an occurence if we want

And delete the server data folder: Emby Server Data Folder if you have an issue on the beta channel make sure to report it in the testing area. thanks.

Right that’s why I asked this. What did it show before?

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

What does the description tell you?

Swamp people

@sa2000FYI, the memory spike occurred this morning again on the first scan of the morning. The previous scan had occurred six hours prior. What was different this time is it occurred while I was running scans of specific libraries instead of doing a manual scan using the scheduled task. And it was during scans of the movie/collections/playlists libraries. I didn't have debug logging turned on in Emby, and I wasn't running the memory usage script at the time. So unfortunately I don't have any detailed logs or a csv of the memory usage to provide. Anyway, I suspect you will get much better input from @DiabboVerddegiven the thoroughness of their past posts. But let me know if there is anything I else I can do to help troubleshoot this.

Great question @flashls82I actually see this fitting in as both a perfect companion to Dispatcharr and a lightweight alternative to it. Dispatcharr is great at the big-picture stuff, like managing multiple providers and failover routing. The problem is that Emby, Channels DVR, and Jellyfin (this isn't isolated to just Emby) still kill streams and ruin recordings during those tiny gaps when Dispatcharr is swapping sources. If you feed Dispatcharr’s output through my solution, it acts as a shock absorber. During a stream stall or source swap, it holds the pipe open and feeds the DVR an outage slate. Dispatcharr gets all the time it needs to switch, the client never detects a dead socket, and your recordings stay completely safe. (And if you don't need multi-provider routing at all, it works perfectly as a standalone, lightweight watchdog proxy). On the technical side, the engine is built on a custom, hardware-accelerated stream orchestration layer. Processing feeds, generating slates, and managing the ring buffers for each virtual tuner—which run directly in RAM for maximum performance (highly preferred)—are all offloaded to the GPU (AMD AMF, Intel QuickSync, NVIDIA NVENC, and Apple VideoToolbox). There is a software libx264 fallback and a direct -copy option for raw MPEG-TS passthrough for setups without hardware, but they run in a more limited capacity just to stitch the stream and the slate. GPU is the gold standard here. It stops your CPU from choking when running multiple recording sessions, and it transcodes everything into a standardized, highly compatible stream. Because of that, timeline seeking and scrubbing on your clients becomes smooth as butter.

Well, that part is is discouraging. I just rolled back to Beta 4.10.0.11 to see if the issue occurs as frequently as does it after updating to 4.10.0.15 and beyond. If you're seeing the issue on the Stable release, I suspect I'm not likely to see anything different. It is very strange that this only started occurring for me mid-June. I don't recall this occurring prior to that. Or at least if it occurred I wasn't aware of it as Emby didn't crash. I checked Resource Monitor memory usage over the past six months. And although I can't see specifically what Emby's memory usage is, I can see that there aren't any sudden spikes in memory prior to mid-June. Having said that, if the spike occurred and memory was returned shortly afterwards it probably wouldn't show up.

A complicating factor now is the fact that neither collections nor playlists have a strict, defined order. So, what is "next"...?

You can send me logs and memory usage logging and I will have a look and see if there are clues as to why sometimes the scans lead to this

I know there is a problem with frequent scheduled scans and that is why, whilst this issue remains, the advice I have been given is to have very infrequent periodic scans. Normally a number of hours would be needed of not doing any scans before any memory gets purged So suggestion is to set the frequency as once daily or not have it automatic and manually scan specific libraries The first scan after the launch of emby server always uses up more memory than subsequent scans. The gap between scans needs to be high to allow memory to get released It has been seen that sometimes memory does start climbing and climbing - but a period of no activity should result in memory being released - that may vary from one OS to another and the releasing of memory may only happen on some when there is need for it

I have a simple feature request. Currently, the "Continue Watching" section on the home screen displays series that have unwatched episodes remaining and movies that have been started but not finished. It would be great to have a "Sagas to continue" section (or to include this logic within the existing "Continue Watching" section). Essentially, if a movie within a collection has been watched, but there are still unwatched movies in that same collection, the system should display the first unwatched movie from that saga in the "Continue Watching" list. I think another section that one could hide or show is the best option, but at least in theexisting section. Thank you!

You're right @DarWun, there are many similiarities. It's not something of DSM or even Emby version, because I'm using the latest "production" version of Emby while you are using the beta. I thought about installing an older version of Emby but I'm unsure this will solve the problem. It is definitely linked to the periodoc library scans/validation/refresh, which I have set for every 30 minutes on my server. Something related to this process is allocating a lot of memory and not giving it back. The scan of all my library takes about 2 minutes and then the process returns to "sleeping" state. When the problem is happening, during the scan the memory is allocated and never de-allocated so it will stay at that same level until the next execution and so on... until a few hours later it eats up all the memory in the box and the kernel kills emby. it is happening again here as we speak. I am collecting as much data as I can but I don't think we mere mortals have access to what this library scan process does under the hood so we probably need someone from Emby to take a look. I have all logs created by Emby plus the full history of memory usage and allocation... everything. Here's how it's looking right now: "Emby" is how much memory the process is using right now, "Emby HighWaterMark" is the maximum amount of memory ever used by the process. I use it as a kill/restart detector. It only goes down if the process dies and a new process is opened for Emby. And "Total Used" is the total memory usage for the Synology box. The library scans happen with no issue, allocating and de-allocating memory just fine for some time, then the mysterious thing happen and from that moment on it can't deallocate memory anymore. And it will keep eating up more and more memory until the OS kills it. This is a challenging debug. But I feel the Emby logs alone don't have all the information to help me isolate what is the exact thing that's screwing the library scans. Anyway I have plenty of debug logs if anyone wants to take a crack at it.

Thanks very much for those logs. I think I can get the app producing audio again but you guys with very limited audio support setups (like using an optical connection) will probably be better off using the standard app. Thanks.

Hi, there's already an open request for this or something functionally equivalent. Please join in and contribute to the existing discussion at:

Hello, I have a simple feature request. Currently, the "Continue Watching" section on the home screen displays series that have unwatched episodes remaining and movies that have been started but not finished. It would be great to have a "Sagas to continue" section (or to include this logic within the existing "Continue Watching" section). Essentially, if a movie within a collection has been watched, but there are still unwatched movies in that same collection, the system should display the first unwatched movie from that saga in the "Continue Watching" list. I think another section that one could hide or show is the best option, but at least in theexisting section. Thank you!

Hi. Please see: Is there a limit to Emby Premiere? You can use the same key on two servers but the devices will be cumulative between them.