fix: correct user-level flatpak mpv path (io.mpv.Mpv, not io.mpv/Mpv) - #1863
Merged
port19x merged 4 commits intoAug 11, 2026
Merged
Conversation
TigerShark900
force-pushed
the
fedora44-flatpak-mpv-fix
branch
from
August 10, 2026 21:20
20a487e to
6846a19
Compare
Collaborator
|
Hey @TigerShark900 good catch! |
port19x
requested changes
Aug 11, 2026
port19x
left a comment
port19x
left a comment
Collaborator
There was a problem hiding this comment.
This one is not necessary, as flatpak availability is implicity checked via the dep_ch_failover function.
Fedora Workstation ships no mpv package by default (needs RPM Fusion, off by default), so most Fedora users install mpv via Flatpak/GNOME Software. The Linux player-detection path checked for a directory at $HOME/.local/share/flatpak/app/io.mpv/Mpv/ (slash), but the real Flatpak app-id directory uses dots throughout: io.mpv.Mpv. That check could never match a real user-level flatpak install of mpv, so ani-cli would die with "No player found. Looked for mpv and vlc" even when mpv was correctly installed. Confirmed against live Flathub metadata (flatpak remote-info io.mpv.Mpv -> Ref: app/io.mpv.Mpv/x86_64/stable) and by simulating dep_ch_failover against both path forms. The system-wide path (/var/lib/flatpak/app/io.mpv.Mpv/, added in b0993d4) was already correct and is unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The post-detection dependency check (dep_ch on \$player_function) had
no case arm for the flatpak-resolved path, so it fell through to the
generic \`dep_ch "\$player_function"\`, which runs \`command -v\` on a
literal directory path like /var/lib/flatpak/app/io.mpv.Mpv/ and
always fails ("Program ... not found. Please install it.") even
though play_episode() already knows how to launch it via
\`flatpak run io.mpv.Mpv\`. Confirmed live: after fixing the
detection path in the previous commit, this was the very next error
hit when actually installing mpv system-wide via flatpak and running
ani-cli for real. Added a matching *flatpak*mpv* arm that checks for
the flatpak binary itself instead.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
TigerShark900
force-pushed
the
fedora44-flatpak-mpv-fix
branch
from
August 11, 2026 07:53
c116ed7 to
eb03ec3
Compare
Collaborator
|
That first commit makes sense, but I don't see the purpose of explicitly checking for a flatpak binary when the very specific flatpak paths do exist |
Collaborator
port19x
approved these changes
Aug 11, 2026
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
2 participants
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.
Summary
Fixes ani-cli failing to find/launch mpv on Fedora 44 Workstation (and any distro where mpv is installed via Flatpak rather than a native package). Fedora ships no
mpvpackage by default — it needs RPM Fusion, which isn't enabled out of the box — so most Fedora users install mpv via Flatpak/GNOME Software instead. Two separate bugs in the Linux player-detection path stack on top of each other to break that case entirely:1. Wrong user-level flatpak path (
ani-cliline ~410)The Linux fallback in b0993d4 added a correct system-wide flatpak path check (
/var/lib/flatpak/app/io.mpv.Mpv/) but the existing user-level path ($HOME/.local/share/flatpak/app/io.mpv/Mpv/) has a typo: a slash where the real flatpak app-id uses a dot. Flatpak's real app-id directory is alwaysio.mpv.Mpv(confirmed viaflatpak remote-info flathub io.mpv.Mpv→Ref: app/io.mpv.Mpv/x86_64/stable, and the layout of other installed flatpaks on a real system, e.g.app/com.brave.Browser/). As written,io.mpv/Mpvcan never exist, so a genuine user-level flatpak install of mpv is never detected.2. Missing case arm in the post-detection dependency check (
ani-cliline ~513-519)Even once
player_functioncorrectly resolves to the flatpak path, a second, separate check (dep_ch "$player_function") re-validates it withcommand -v, which fails on a literal directory path like/var/lib/flatpak/app/io.mpv.Mpv/— even thoughplay_episode()already knows how to launch it viaflatpak run io.mpv.Mpv. This check had no*flatpak*mpv*arm to skip past it, unlikeplay_episode(), so it always dies withProgram /var/lib/flatpak/app/io.mpv.Mpv/ not found. Please install it.Both bugs had to be fixed for flatpak-installed mpv to work at all on Linux, system-wide or per-user.
Test plan
sh -n ani-clipassesflatpak install flathub io.mpv.Mpv(system-wide, matching GNOME Software's default), confirmed each error in sequence (No player found...→Program /var/lib/flatpak/app/io.mpv.Mpv/ not found...), fixed both, then ranani-cliend-to-end and confirmed playback actually worksdep_ch_failoveragainst both the correct (io.mpv.Mpv) and buggy (io.mpv/Mpv) user-level paths to confirm the exact failure mode before the fixflatpak remote-info --user flathub io.mpv.Mpv🤖 Generated with Claude Code