An FFmpeg that setup rejected is still what yt-dlp gets, and still first on PATH #651

What goes wrong

Setup can decide the FFmpeg in the data directory is unusable and settle on another one. Since #643 it does exactly that: a pair that fails verification is left behind and the search falls through to a system FFmpeg or a fresh download.

The backend is told the winner. apply_ffmpeg_path sets STEMDECK_FFMPEG and STEMDECK_FFPROBE to the verified pair, and ffmpeg_executable() / ffprobe_executable() honour them.

Two other paths never got the message, and both still point at the rejected copy.

1. configure_portable_environment() prepends FFMPEG_DIR to PATH whenever that directory exists (app/core/config.py:465). It runs at import time from app/main.py:102, after the shell has put the verified directory on PATH, so the rejected one ends up in front of it. Anything resolving a bare ffmpeg or ffprobe finds the binary setup threw out.
2. yt-dlp is handed ffmpeg_location = FFMPEG_DIR unconditionally (app/pipeline/download.py:216). That is an absolute location, so there is no PATH search to fall past it. Every YouTube import that remuxes or extracts audio uses the rejected binary.

FFMPEG_DIR is _env_path("STEMDECK_FFMPEG_DIR", DATA_DIR / "ffmpeg"), and nothing in the desktop shell sets STEMDECK_FFMPEG_DIR. So in a desktop install it is always the data directory, whatever setup concluded about what lives there.

Who hits it

Anyone whose data-directory FFmpeg fails verification while another one works:

• The Apple Silicon case from [Bug]: 启动任务失败:Could not read file duration: [Errno 86] Bad CPU type in executable: '/Users/bigbang/Library/Application Support/StemDeck/ffmpeg/ffprobe' #637. An Intel pair sits in the data directory, setup falls through to a working system FFmpeg, separation works, and a YouTube import fails with "Bad CPU type in executable".
• Any platform where the downloaded build is missing a required encoder. verify_ffmpeg_encoders rejects it, setup moves on, and yt-dlp is still given it.

The confusing part for whoever reports it is that the app works. Local files separate and export normally. Only the download path breaks, and the error names a binary the app supposedly stopped using.

Constraints for whoever fixes it

• The verified answer already exists in the environment as STEMDECK_FFMPEG and STEMDECK_FFPROBE. Deriving the directory from those is likely simpler than adding another variable, but they are absent in Docker and in a source checkout, where PATH is correct and FFMPEG_DIR does not exist. Both have to keep working.
• STEMDECK_FFMPEG_DIR is set by hand in source runs where FFmpeg is not on PATH. A fix should not stop honouring it when it is set.
• Deleting the rejected directory is not the answer on its own. Catch a wrong-architecture FFmpeg, and say what it is #643 deliberately leaves an explicit STEMDECK_FFMPEG override alone, and a later launch may replace the contents with a working pair.
• yt-dlp takes one directory, not two paths, so whatever is chosen has to be a directory holding both ffmpeg and ffprobe.