All Activity

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.

@SuperCitizenEmbhave you had any chance to work on this further? Something like an Emby plugin would be fantastic

all set thanks

Hi. Many of your requests are already possible but please post single feature requests in a single topic so we can track them appropriately. Thanks.

Hi My router was recently reset by my ISP during troubleshooting. I can no longer access Emby remotely. On the NAS I have enabled remote access in NMetwork section I have enabled Remote Access under two user accvounts I have set up a port forward rule on the router ShieldsUp now shows the port (8096) as open. Ping gets no response Attempts to connect through my WAN address result in Emby reporting it is trying to connect to an old instance on another server (at least, the server name is the old server). The old server is at an IP that is not set up in port forwarding. Only the current server is in the port forwarding. If I look at emby.media it shows only my current server. In emby client apps the old server is present as well and I cannot delete it from the list. the documentation talks about Emby Connect but I don't believe I am using this as I have no idea of my Emby Connect name and I cannot find it in my Emby account. So I am just using my WAN address and port number 8096. I used to be able to access using just the IP and port... embyserver (7).txt

Actually, there are some similarities to the issue I reported originally. On my NAS the scheduled task for "Scan media library" was set to run every six hours. Throughout the day it would execute automatically without an issue. Memory usage remained stable. But when I ran the task manually first thing in the morning after the NAS had sat idle overnight memory usage immediately jumped from 1GB to 2GB. The DS918+ only has 4GB of ram, and that sudden jump brings total memory utilized to around 90%. If I do anything else in Emby while that is happening, like navigating from the Dashboard to the Home screen, Emby will become unresponsive. Usually Emby shutdown at that point due to an OOM event. A couple of times recently it was able to recover and the memory was released, usually within the next 30minutes provided I didn't do anything else in Emby. For me, this only started happening within the last month. It is occurring fairly frequently now (every couple of days). It occurs first thing in the morning after the NAS has sat idle overnight. You identified that "The process is usually sleeping after the scan completes while still holding all of the allocated memory." When the memory usage spike occurred again this morning, I checked the process status. Emby was sleeping. One thing I noticed is that you are still on DSM 7.3.2. I started seeing the issue just after updating to DSM 7.4-90075. That was coincidentally around the same time that I updated to Emby Beta 4.10.0.15. So I couldn't rule out that it was the DSM upgrade that was the culprit. The fact that you are seeing this on an earlier version of DSM might be evidence that the newer version of DSM is not the culprit.

I played around a bit with the various settings and enabled that function as well. However, it seems I didn't anticipate the result and forgot where I had activated it. I find the description of the function isn't entirely clear. But now ... I know