All Activity

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/Plex 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.

Oh nice, perfect, thanks for the quick response. While I wait on that, do you have any recommendations how I can best resolve my metadata problem? Even a restart of Emby server doesn't seem to resolve the "cancelling connection" issue...

The upcoming 4.10 release has added the ability to design your own home screen sections, so you can control this.

I'm also keen to simply have the posters displayed under the Continue Watching list... even IF I fix my current problem... My underlying reason I was looking for a solution to this is that fanart.tv appears to have some rate limiting that means half way through my metadata scan for all my media it started importing broken links and I'm getting the error: "Cancelling connection to https://assets.fanart.tv/fanart/#WHATEVER#.jpg due to a previous timeout." whenever I try to access one of their images. The problem is now half my content has broken thumbnails links, and I don't seem to be able to resolve it. Emby appears to have cached the fact the link has timed out and doesn't ever try to access the file again, despite the fact I'm able to visit the link directly from the same computer and download it. So basically, everything that now goes into my Continue Watching list ends up with a broken image placeholder. I'm not sure about the best way to go about fixing this... even the metadata manager doesn't really expose the mass editing capability I need to make this a pain free exercise.

Always the early adopter! I didn’t think it would be an issue since the previous version worked fine and other apps also seem stable. If it is an ARM issue then I guess there’s nothing I can do about that.

Yes it’s the ARM64 version of Windows 11

What was the solution?

Not as far as I recall. Is this an known problem? If so, is there any more info needed?

Nope. But i solved it on my own.

Try V 1.2.0.0

New Release v 1.2.0.0 Added New: "Leaving Soon" collection sync — mirrors the delete queue into a real Emby collection, toggle + customizable name in Settings, fully managed membership (auto add/remove as items are queued, un-queued, or deleted). EmbyExpiry.dll

HI, has this helped?

Probably a plugin being updated. the server dashboard will say what was updated at that time.

Turn off your emby server and tell me how many friends you have jk

SMS message or WhatsApp and I add it manually. I only share access with people I have personal relationships with so they can message me directly if they want something or need tech support. I have friends, not clients.

Sorry

Just wondering did anyone else get that restart prompt the other day for updates? I don't see anything update after I restarted. Luke?

I got it running! Thanks for your help!

What does this even mean? Isn't this already a thing ?

Did you make sure to open it by following the instructions here: https://emby.media/mac-server.html

Same way I always do. Put it in my download folder, opened the zip file, placed the EmbyServer.app file into the Applications folder, then opened it. Clicked it once, then had to click on it again to open it. The file I downloaded was the one labeled "macOS 10.13" and reads "embyserver-osx-x64-4.7.14.0.zip" when the download pops up. As I said in the earlier post, I usually download the "macOS 10.14+ X64" file, but that file was not there. The link only opens up a browser page that says "Not Found".