Synology DSM 7.4.1: all transcoding fails ("No video encoder found for 'h264'"). emby-ffmpeg wrapper segfaults

[vince7585 1]

 

ENVIRONMENT
- Emby Server 4.10.1.0 (package emby-server-synology72, x86_64)
- Synology DS1821+ (AMD Ryzen V1500B, no iGPU)
- DSM 7.4.1-90080 (build date 2026/07/22), kernel 4.4.302+
- System glibc: 2.36. glibc bundled with Emby (/var/packages/EmbyServer/target/lib/libc.so.6): 2.34

SYMPTOM
Every playback that needs transcoding or remuxing spins for a long time and then fails on the client ("too many errors" on Android TV). The server log repeats:

    FfRunException: No video encoder found for 'h264'

Hardware detection at startup shows every ffmpeg probe crashing:

    FfmpegManager: ProcessRun 'ffmpeg -hide_banner -version' Execute: /var/packages/EmbyServer/target/bin/emby-ffmpeg -hide_banner -version
    FfmpegManager: ProcessRun 'ffmpeg -hide_banner -version' Process exited with code 139 - Failed
    (same for -decoders, -encoders, -hwaccels, -protocols, -filters)

So the FfmpegCapabilities list ends up empty, and no encoder (not even libx264) is available.

ROOT CAUSE
emby-server exports LD_LIBRARY_PATH=$APP_DIR/lib for the EmbyServer process. EmbyServer then runs the wrappers emby-ffmpeg, emby-ffdetect, emby-vainfo and emby-clinfo, which are #!/bin/sh scripts. The system /bin/sh (bash) inherits that LD_LIBRARY_PATH. It is loaded by the system's glibc 2.36 ld-linux, which then picks up Emby's bundled libc.so.6 (2.34), and bash segfaults before the script runs.

Reproduction over SSH (no Emby involved):

    LD_LIBRARY_PATH=/var/packages/EmbyServer/target/lib /bin/sh -c true   # -> Segmentation fault (139)
    /bin/sh -c true                                                        # -> 0

Testing each library in target/lib one at a time shows that libc.so.6 alone triggers the crash.

WORKAROUND (confirmed working)
Change the shebang of the wrapper scripts so that bash runs under Emby's own loader, which matches the bundled libc:

    A=/var/packages/EmbyServer/target
    cd "$A/bin"
    for s in emby-ffmpeg emby-ffdetect emby-vainfo emby-clinfo; do
      sudo cp -a "$s" "$s.orig"
      sudo sed -i "1s|.*|#!$A/lib/ld-linux-x86-64.so.2 /bin/bash|" "$s"
    done
    sudo synopkg restart EmbyServer

After this change every startup probe exits with code 0, the encoders are detected again, and software transcoding (libx264) works.

SUGGESTED FIX
Either avoid running system binaries such as /bin/sh with LD_LIBRARY_PATH pointing at the bundled glibc (for example, don't export it globally in emby-server, or have the wrappers clear it before the shell starts), or ship the wrappers with an interpreter that matches the bundled libc, as in the workaround above.
 

Edited October 10 by vince7585

[Luke 43374]

HI, we'll take a look at this. Thanks.

[alucryd 344]

@vince7585If you're willing to give beta a try, it does away with LD_LIBRARY_PATH and uses RPATH trickery instead, allowing mixing of system binaries with ours without interfering with each other.

Edited October 10 by alucryd

[vince7585 1]

I just try Version 4.11.0.7 beta and it works.