Change:
<del> { lib , mpv-unwrapped , ocl-icd , ... </del> <ins> { lib, mpv-unwrapped, ocl-icd, </ins> }: mpv-unwrapped.wrapper {

Discussion:
Package name: svp Latest released version: 4.6.263 <!-- Search your package here: --- Current version on the unstable channel: 4.5.210-2 Current version on the stable/release channel: 4.5.210-2 <!-- Type the name of your package and try to find an open pull request for the package If you find an open pull request, you can review it! There's a high chance that you'll have the new version right away while helping the community! --- Notify maintainers <!-- If the result shows no maintainers, tag the person that last updated the package. --Note for maintainers: Please tag this issue in your PR. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
New version solves and makes obsolete.
Opened PR

When changing an SVP option during playback or the played file in mpv, starting from mpv 0.37.0, due to , it spams: and SVP no longer reports any connected player at the bottom of its window after that. top left logo, "Open file via mpv", pick a video the video is playing, switch back and forth between one of the buttons under "Do frame rate conversion" like "To screen" and "Movie x2" In mpv 0.36 and earlier, it says: and SVP keeps working normally. SVP has no source code available and new versions haven't been released on Linux since 2021, while mpv 0.37 came out in November 2023, making it unlikely to be fixed upstream any time soon. I've made a dirty workaround by to re-add the option, and overriding the source of the mpv package in my flake + home-manager setup. Handling both the external mpv package and the one within SVP's (the mpv that gets used by SVP's in-GUI "Open file") gets complicated - here are the relevant parts: Please run and paste the result. Add a :+1: [reaction] to [issues you find important]. [reaction]: [issues you find important]:
Thanks for your investigation! Indeed it looks like modifying mpv to add the option back is the best way. Based on the diff on your fork, the change seems small enough for us to maintain. On the other hand, patching SVP is impossible due to its tamper protection.
A couple questions: the mpv package gets updated, it might break building SVP with the patch. Do github checks catch these cases, or will the SVP package just be broken until someone else notices? I give you push access to the forked repo, to rebase and regenerate the patch as needed? I rarely update my system, so the repo will likely be left randomly outdated until I have to take care of it. you make the SVP package take and overridable parameters, so that it isn't so hard to e.g. add scripts to the internal mpv? to make a standard external mpv connect to SVP will fail since it won't be patched, is there a good way to indicate to users that they should install in their environment?

The parameters mentioned above should probably also be made known.
package in nixpkgs will be broken. However I also have this SVP package on my NUR, and have daily CI runs to rebuild packages, so once it breaks I will notice and make a fix. isn't necessary. I can rebase the patch on mainline mpv as needed. will add them. can't think of any good way for now.