`mpv --version` is wrong in latest mpv packages

[odrling]

Hi, I've been trying to use mpv in a github action for integration test and noticed this issue in the latest mpv/mpvio packages.

> Run mpv --version
mpv 1c9c2f5 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
 built on Dec 10 2023 12:02:37
libplacebo version: v6.338.0-62-g52314e0-dirty
FFmpeg version: N-112938-g12e25af7a
FFmpeg library versions:
   libavutil       58.32.100
   libavcodec      60.35.100
   libavformat     60.18.100
   libswscale      7.6.100
   libavfilter     9.14.100
   libswresample   4.13.100

The version seems to use the hash from https://github.com/shinchiro/mpv-winbuild-cmake/commit/1c9c2f50e5ced9426a1ac3d74d9841379dfa3d83 instead of the actual version of mpv.

I've tried the releases from sourceforge on a Windows computer and noticed the same issue on the 0.37.0 build but the latest build at this time (mpv-x86_64-v3-20231231-git-abc2a74.7z) does seem to return a correct version.

Could you update the mpv package to a newer build that doesn't have this issue and maybe also fix it for mpvio although it seems like a slightly more involved fix.

Thanks!

(PS: I also couldn't get it to work with choco install mpv --version=2023.01.28 and I'm not sure why, it seems to still install the latest version)

[AeliusSaionji]

(PS: I also couldn't get it to work with choco install mpv --version=2023.01.28 and I'm not sure why, it seems to still install the latest version)

Hm, I don't know why that would be happening, but you could try choco install mpv.install --version=2023.01.28

The version seems to use the hash

Yeah, I've noticed this on a few other occasions too. shinchiro's releases are, I think, mostly a favor added in for me and this chocolatey package, so they probably don't get as much scrutiny as shinchiro's bleeding edge builds. They might even be hand picked (hence the occasional mistake)

But I can't select an arbitrary build with arbitrary commits and call it mpv 0.37.0 What I can do is sit down and add chocolatey's --beta support for this package, although that won't fix your issue because there's no guarantee the beta builds will have a scrape-able version.

I can point you in the direction of a CI-able mpv build, though:

• How to use msys2 in github actions https://www.msys2.org/docs/ci/
• The mpv package https://packages.msys2.org/package/mingw-w64-ucrt-x86_64-mpv?repo=ucrt64

[odrling]

Hm, I don't know why that would be happening, but you could try choco install mpv.install --version=2023.01.28

I thought I had tried it but it works fine now. Must have been some kind of PEBKAC sorry for that. The mpv package doesn't behave well with this flag and always installs the latest version of mpv.install, but it is just a minor inconvenience.

But I can't select an arbitrary build with arbitrary commits and call it mpv 0.37.0

I was rather thinking about rebuilding mpv 0.37.0 while avoiding this (minor) issue. Similar to how some distributions would rebuild packages to link with an updated library or add patches that affects their users. Generally they would call it 0.37.0-r1 and not clash with the upstream versioning system. That said I was under the impression that the mpv package was following the "git" builds while mpvio followed the releases but now I notice that the dates of the versions match the last few mpv release dates. So both packages are supposed to have equivalent versions.

I can point you in the direction of a CI-able mpv build

Chocolatey seemed more convenient than using other package managers in github actions due to being included in the windows image. I don't think this particular CI would make a particularly good use of msys2 because it really only need the mpv executable in the PATH.

What I can do is sit down and add chocolatey's --beta support for this package, although that won't fix your issue because there's no guarantee the beta builds will have a scrape-able version.

I'm fine with using an older fixed version in the CI, at least for the time being, so I think I will just do that. For a regular user the version is probably not much of an issue though, so I think this can be closed.