Fix AMDGPU_IDS_PATH so libdrm can find amdgpu.ids#119
Open
Sausageroll2077 wants to merge 1 commit into
Open
Conversation
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>
0536882 to
a153a49
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:What I can verify (Intel host,
emby:beta, 4.10.0.15):/app/emby/extratree is absent from the image.grep -rI AMDGPU_IDS /app/embyfinds no consumer of the variable nameAMDGPU_IDS, so that line appears to be a no-op./app/emby/share/libdrm/amdgpu.ids./app/emby/bin/emby-ffmpeg,emby-server, etc.) instead exportAMDGPU_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:
What I could NOT verify (please confirm):
AMDGPU_IDS_PATHat runtime — I found no matching string inlibdrm_amdgpu.so, and libdrm may fall back to a working default.amdgpu.idsis 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. IfAMDGPU_IDS_PATHis consumed on AMD, this lets libdrm resolveamdgpu.idscorrectly.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 theAMDGPU_IDSname, and the wrapper scripts' use ofAMDGPU_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-ffmpegetc.) exportAMDGPU_IDS_PATH=$APP_DIR/share/libdrm/amdgpu.ids.