Skip to content

Fix AMDGPU_IDS_PATH so libdrm can find amdgpu.ids#119

Open
Sausageroll2077 wants to merge 1 commit into
linuxserver:betafrom
Sausageroll2077:fix-amdgpu-ids-path
Open

Fix AMDGPU_IDS_PATH so libdrm can find amdgpu.ids#119
Sausageroll2077 wants to merge 1 commit into
linuxserver:betafrom
Sausageroll2077:fix-amdgpu-ids-path

Conversation

@Sausageroll2077

@Sausageroll2077 Sausageroll2077 commented Jun 19, 2026

Copy link
Copy Markdown

linuxserver.io


  • I have read the contributing guideline and understand that I have made the correct modifications

Description:

Heads up: I only have Intel hardware, so I could not test this on an AMD GPU. I'm raising it because the env line looks dead/misnamed and there's a probable fix — but it needs confirmation from an AMD GPU owner before being relied upon.

In root/etc/s6-overlay/s6-rc.d/svc-emby/run, the service exports:

export AMDGPU_IDS="${APP_DIR}"/extra/share/libdrm/amdgpu.ids

What I can verify (Intel host, emby:beta, 4.10.0.15):

  • That path does not exist — the whole /app/emby/extra tree is absent from the image.
  • grep -rI AMDGPU_IDS /app/emby finds no consumer of the variable name AMDGPU_IDS, so that line appears to be a no-op.
  • The real table ships at /app/emby/share/libdrm/amdgpu.ids.
  • Emby's own bundled wrapper scripts (/app/emby/bin/emby-ffmpeg, emby-server, etc.) instead export AMDGPU_IDS_PATH=$APP_DIR/share/libdrm/amdgpu.ids (note: different variable name). The service runs the raw /app/emby/bin/ffmpeg, not those wrappers, so it doesn't inherit that value.

This PR aligns the service env with Emby's own wrappers:

-export AMDGPU_IDS="${APP_DIR}"/extra/share/libdrm/amdgpu.ids
+export AMDGPU_IDS_PATH="${APP_DIR}"/share/libdrm/amdgpu.ids

What I could NOT verify (please confirm):

  • Whether anything actually reads AMDGPU_IDS_PATH at runtime — I found no matching string in libdrm_amdgpu.so, and libdrm may fall back to a working default.
  • Whether AMD users see any real impact. amdgpu.ids is a PCI-ID→name lookup table, so worst case is likely a cosmetic blank/generic adapter name rather than broken transcoding.

Benefits of this PR and context:

Aligns the service's hardware-accel env with the values Emby's own emby-* wrapper scripts use, and removes a dead/misnamed env line. If AMDGPU_IDS_PATH is consumed on AMD, this lets libdrm resolve amdgpu.ids correctly.

How Has This Been Tested?

Not tested on AMD hardware (I don't have an AMD GPU). On an Intel host I verified the filesystem facts above (missing extra/ path, real file location, no consumer of the AMDGPU_IDS name, and the wrapper scripts' use of AMDGPU_IDS_PATH). Could an AMD GPU owner confirm whether this changes hardware detection / VAAPI behaviour on AMD?

Source / References:

Emby's bundled wrapper scripts in the image (/app/emby/bin/emby-ffmpeg etc.) export AMDGPU_IDS_PATH=$APP_DIR/share/libdrm/amdgpu.ids.

@aptalca aptalca left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please rebase

The run script exported AMDGPU_IDS=/app/emby/extra/share/libdrm/amdgpu.ids,
which (a) points at a path that does not exist in the image (the whole
/app/emby/extra tree is absent) and (b) uses a variable name nothing in
the image reads. Emby's own bundled wrapper scripts (emby-ffmpeg etc.)
instead export AMDGPU_IDS_PATH=$APP_DIR/share/libdrm/amdgpu.ids, and the
real table ships at /app/emby/share/libdrm/amdgpu.ids.

Align the service env with Emby's wrappers. Note: this could not be
tested on AMD hardware; flagged for confirmation by an AMD GPU owner.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@Sausageroll2077 Sausageroll2077 requested a review from aptalca June 19, 2026 12:05
@LinuxServer-CI LinuxServer-CI moved this from PRs to PRs Ready For Team Review in Issue & PR Tracker Jun 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: PRs Ready For Team Review

Development

Successfully merging this pull request may close these issues.

3 participants