All Activity

Thanks — that clears it up, and re-checking my log you're right: on the Apple TV the play sessions do close before the next one opens (every "Removed" precedes the next "Adding" by ~1.7–2s, and that container never holds more than 1). So that wasn't the right case to lead with, sorry. Re-running concurrency per session container, though, I do have two cases where a container genuinely holds 2 open play sessions: 1) Emby for Android 3.5.36, single tablet, same title — the old play session is re-added 21 ms after the new one opens, and both stay open for ~61 s: 14:29:33.720 Removed playSession 9e8b4d46... from session 84659c77... 14:29:33.720 Adding playSession 25977433... to session 84659c77... <- new one opens 14:29:33.741 Adding playSession 9e8b4d46... to session 84659c77... <- OLD one re-added, +21ms 14:30:34.783 Playback stopped reported by app Emby for Android 3.5.36 14:30:34.786 Removed playSession 9e8b4d46... from session 84659c77... <- 2 open for ~61s 2) A play session added that never starts playback and is never removed, sitting alongside a real one: 16:14:33.362 Adding playSession 6c643c46... to session d2d1f2d0... <- no "Playback start", ever 16:14:33.895 Adding playSession a422bee1... to session d2d1f2d0... <- Emby for LG 1.0.50, real playback -> container now holds 2; 6c643c46 is never removed for the rest of the log Server-wide it's 53 "Adding playSession" vs 49 "Removed" over the day. So: In (1), if the client is meant to wait for the first to close, what would cause it to re-add the previous play session after the new one has already opened? In (2), if the first one never closes (app killed, network drop, or a session that never starts playing), does it keep counting against the limit? Is there a server-side timeout that reaps stale sessions, and how long is it? Note this log doesn't actually contain a "limit exceeded" event — I'll enable debug logging and post one that captures the moment the user hits the error.

I don't think it is relevant. Both of the example songs have an artist of some sort per Emby's own terminology. Don't miss the point here: UI between songs has to be consistent.

Hi, thanks for sharing. We will have anew ffmpeg build on the server beta channel very soon.

Hi, did you check what user24 mentioned?

The toggle has been added for the next app update.

It’s actually intended to wait for the first one to close before attempting to open the second.

That’s afterwards though right. The activity log would say if a plugin was updated.

That's why I was asking it always shows before restarting what it's updating and after reboot it even shows but this time it never showed a thing lol.

Yeah, that indicates that Emby is not closing the stream fast enough for some reason.

@Natelanxon Thanks for the details - so what you are trying to do is Run an x64 application with heavy use of GPU features (by both, WebView2 and MPV player) - on Windows ARM64 OS With the Windows ARM64 OS running in a virtual VM on Apple Silicon hardware Even though translation layers exist for running x64 code on ARM64 (Windows Prism) and Windows GPU drivers for the virtual GPU provided by Parallels which translates to Apple GPU - this is not a path which makes much sense. To be honest, I'm surprised that our x64 app package is even offered to ARM64 systems, but they appear to be somewhat over-confident about the x64 emulation layer. The fact that you don't ´see any log at all, means that it drops out very early during load, but it still can be due to both, WebView2 or MPV player. We'll probably need to publish an ARM64 package with an ARM64 web view and without MPV player, to have a working version at least. Thanks

As I could see, if I set the limit to 2, the problem dissapears and sometimes, shortly, there are two streams, but suddendly one dissapears.

What i meant was, if you remove the limit does the server dashboard show the same account have multiple streams running. While chances are low that it shows anything it is still an easy little troubleshooting step.

Have video media in folders like tv, movies, .... When I select the movie library I want o see all the movies. It seems like thats how it was before, but now it appears that I might just be seeing a specific genre.

Powered up monitor Select Emby Android TV app User 'TestAdmin' 'Dark Matter' S2E13 is the first icon in 'Continue Watching' Get MediaInfo report on file: Dark Matter - S01E13 - Episode Thirteen.mkv Matroska: 4.05 GiB, 43 min 6 s Title: Dark Matter S01E13 Episode Thirteen 1080p Blu-ray 10Bit TrueHD5.1 HEVC-d3g 1 video stream: HEVC Encoded date: 2022-11-09 09:36:45 UTC 1 audio stream: MLP FBA Writing application: DVDFab 12.0.9.1 1 text stream: PGS Writing library: libebml v1.4.2 + libmatroska v1.6.3 First video stream 11.4 Mb/s, 1920*1080 (16:9), at 23.976 (24000/1001_FPS, HEVC (Main 10@L4@High) First audio stream English, 1 969 kb/s, 48.0 kHz, 6 channels, MLP FBA (Dolby TrueHD) Select episode Hit 'Play' Episode begins, video is perfect, no audio Hit Pause Select disc Down, note 'CC (off)' and 'Direct' are showing Back out of episode twice Sent logs at 4:47PM Pacific time.

Can we have some urgency in fixing this absolutely rubbish view never been more frustrated that we are now using recorded tv. Can we get the old version of the app while this is improved please

Works perfectly, thank you!

Hello. I can't download a stable version of Emby for the qnap. I always get a 404 page not found error. As far as I can see there's a link that is missing the version number and that may be the reason. Kind regards. Will

@ebr@Luke@sa2000

Hi. I have a problem with the plugin. It's imposibleto me, compile the plugin. I need help.. Thanks.

Yep, if I remove the limit or I raise it to two, the problem disaapears... But it has no sense. I mean, the limit is not working. I appreciate your help! Hi Luke, I was wondering about starting this thread a time ago, I tought it was my fault... but I use another server, and now I have the same problem with "1 stream limit" users. I found other threads with same problem, but those thread are dead or fixed with an update... strange. I found that this happens a lot with google chrome, and when changing episodes. Is there a way to raise the limit the server "detects" a stream"? I mean, if the user is limited to 1 stream; the server wait 60 (or less or more) seconds to kill the streams, so the user client has enough time to stop the previous session. Please ask anything you need; thanks,

Hello kadargof, ** 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

My apologies if this topic is in wrong section. I just wanted to share my experience with A310 an WinServer 2025 (Proxmox VM), legacy host. ### [SUCCESS STORY] Full Intel Arc A310 Hardware Encoding & Decoding inside Proxmox VM (Windows Server 2025 Guest) on Legacy non-UEFI Lenovo ThinkStation D20 I wanted to share a major troubleshooting victory for anyone trying to use an Intel Arc A310 GPU for media transcoding in an enterprise server environment. Many guides claim that Intel Arc GPUs absolutely require modern UEFI and Resizable BAR (ReBAR) support to avoid crashing or hitting Code 43 errors. My setup proves that for specialized Emby video transcoding workloads, you can run an Arc A310 flawlessly on a legacy PCIe 2.0 system without UEFI or ReBAR options. Furthermore, I hit the infamous Windows Server trap where the GPU would successfully handle **Decoding**, but **Preferred Hardware Encoders** would stubbornly revert to "Software Encoders." This was compounded by the fact that simply logging in via Microsoft Remote Desktop (RDP) would secretly hijack the driver and kill the encoders. Here is the exact step-by-step blueprint to fix the missing frameworks, bypass the OS driver locks, and sandbox RDP so everything stays running perfectly in hardware 24/7. --- ### Phase 1: Motherboard & Hypervisor Base Setup 1. **Physical Loop:** Ensure a physical HDMI dummy plug dongle is firmly connected to the back of the Intel Arc A310 card. Headless server operating systems will refuse to initialize the encoding engine without an active display loop. 2. **Proxmox Passthrough:** Standard GPU passthrough rules apply. Ensure `iommu=pt` is enabled in your host boot options. Pass the card through to your Windows Server 2025 VM (Q35 machine type recommended). --- ### Phase 2: Forcing the Consumer Multimedia Frameworks Windows Server 2025 strips out all consumer multimedia engines by default. This isolates background applications from the Direct3D11 runtime pipelines, causing Emby’s QuickSync initialization module to fail and return a `Result: null` error in your `hardware_detection.txt` logs. 1. **Install Media Foundation & .NET:** Open PowerShell as an Administrator inside the VM and execute: ```powershell Install-WindowsFeature Server-Media-Foundation ``` Ensure you also navigate to Server Manager and install the required **.NET Framework features**. Restart the VM immediately. 2. **Install Legacy DirectX Runtimes:** Download the official offline *Microsoft DirectX End-User Runtimes (June 2010)* package. Extract it to a folder, right-click **`DXSETUP.exe`**, run it as Administrator, and complete the installation wizard. 3. **The Driver Bypass:** Do not run the standard Intel `.exe` installer wizard, as it actively blocks consumer encoding features upon detecting a Server OS. Instead, use 7-Zip to extract the Intel driver installer file into a normal folder on your desktop. * Open **Device Manager**, right-click your Intel Arc display card, and choose **Update Driver**. * Select **Browse my computer for drivers**, point it to your uncompressed folder, ensure **Include subfolders** is checked, and force-inject the raw driver files. 4. **The MediaSDK Registry Hack:** Create a file named `intel_fix.reg` on your desktop using Notepad, paste the following text, save it, and double-click to merge it: ```reg Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Intel\MediaSDK] "DispatchLevel"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Intel\MediaSDK] "DispatchLevel"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Khronos\OpenCL\Vendors] "intelocl64.dll"=dword:00000000 ``` --- ### Phase 3: Trapping RDP in a Software Sandbox When you use native Microsoft Remote Desktop (RDP) to manage Windows Server, the OS stealthily detaches your Intel Arc driver and hooks up the *Microsoft Remote Display Adapter*. This instantly breaks Emby's access to the A310 hardware encoders. To prevent RDP from stealing your GPU, force RDP to run strictly in a software-only rendering sandbox: 1. Press `Win + R`, type **`gpedit.msc`**, and enter the Local Group Policy Editor. 2. Navigate to: **Computer Configuration** ➔ **Administrative Templates** ➔ **Windows Components** ➔ **Remote Desktop Services** ➔ **Remote Desktop Session Host** ➔ **Remote Session Environment**. 3. Apply these exact policy configurations: * **"Use the hardware default graphics adapter for all Remote Desktop Services sessions"** ➔ Set to **Disabled** *(Explicitly stops RDP from touching the Arc A310).* * **"Prioritize H.264/AVC graphics mode for Remote Desktop Connections"** ➔ Set to **Disabled** *(Prevents RDP from spinning up the hardware encoding chips).* * **"Use WDDM graphics display driver for Remote Desktop Connections"** ➔ Set to **Enabled** *(Forces RDP to act as a virtual shield using standard software rendering).* 4. Open Command Prompt as Administrator and run `gpupdate /force`, then restart your Windows Server 2025 VM. --- ### Phase 4: Finalizing Emby Configuration 1. Open Windows **Settings** ➔ **System** ➔ **Display** ➔ **Graphics**. 2. Click **Browse** under custom options and add both **`EmbyServer.exe`** (located under `%appdata%\Emby-Server\system`) and its encoder bin **`ffmpeg.exe`** (located under `%appdata%\Emby-Server\system\ffmpeg`). Set both executables to **High Performance (Intel Arc A310)**. 3. Open Windows Control Panel ➔ **Power Options** and switch your profile profile to **High Performance** to stop the server from aggressively parking the PCIe slots. 4. Exit the Emby desktop tray app entirely, clear the old hardware performance cache by deleting the `%appdata%\Emby-Server\programdata\cache\ffmpeg` folder, and restart Emby Server. ### The Verdict Once Emby finishes compiling its new runtime shaders (you will see tiny Compute spikes on your GPU Task Manager graph), head to your Emby dashboard ➔ **Transcoding** ➔ **Advanced**. Your **Preferred Hardware Encoders** will successfully list: * `QuickSync Intel Arc A310 LP Graphics - H.264 (AVC)` * `QuickSync Intel Arc A310 LP Graphics - H.265 (HEVC)` You can now use your standard RDP windows to manage your server freely without losing hardware transcoding capabilities, achieving zero-buffer instant movie scrubbing on smart TVs paired with steady enterprise-class network file transfer speeds!

@hukt_own_fonikzare you still having an issue with this?

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

I just sent 3 different logs from Emby for Android TV on my Shield TV: one for a Seinfeld episode with DD2.0 sound, one for the Descendants movie with DD5.1 sound, and one for The Avengers Age of Ultron with DTS sound. None of these have sound playing anymore. I sent these around 5:25-5:30 PM Eastern time 7-14-2026 using the account, MediaServer.