Numbers in menu items do not change back to defaults when their bindings are removed

[svobs]

System and IINA version:

• macOS 13.1
• IINA 1.3.1 (latest develop: da1e06c)

Discovered this while investigating #4217.

For some mpv key bindings, IINA sees if they fall within an expected range, and if so, may alter some of its menu items so that they can match. For example, if seek has a value between 5s and 60s, IINA will change its Playback > Step Forward menu item to match its value, and will display its key binding there. But if the user removes the key binding, or changes it in a way that causes it to no longer qualify for the menu item, then the menu item should fall back to its previous value.

Steps to reproduce:

I performed these steps:

1. Open any video using the latest build of IINA. Pause the video near its beginning.
2. Go to Settings > Key Bindings, and duplicate the IINA Default configuration, and make it the active configuration. Make sure Display raw values is checked.
3. Locate the entry for the RIGHT key. Its action should be seek 5.
4. Double-click on its action to edit using the inline editor, and change its action to seek 30. Press RETURN to accept it.
5. Check the Playback menu and confirm that Step Forward 30s is present and has the ⇾ shortcut.
6. Double-click the same action again to edit it, and change it to seek 3. Press RETURN to accept it.
7. Check the Playback menu. You will see that Step Forward 30s is still present but without the ⇾ shortcut. This is incorrect. It should fall back to Step Forward 5s. (If you were to close & reopen IINA at this point, you would see that it will correctly fall back to this value.)

Expected behavior:

In the Playbackmenu, the first item in the second section down should beStep Forward 5s` and have no shortcut. When clicked on, it should step the video about 5 seconds forward.

Actual behavior:
The item in that location is still called Step Forward 30s, and when clicked on, it steps the video about 30 seconds forward.

• MPV does not have this problem.

How often does this happen?
Always

[low-batt]

Reproduced for me following the given instructions

[low-batt]

The fix for this issue has been merged into the IINA develop branch. GitHub automatically closed the linked issue in reaction to the merge. I am reopening this issue until the fix is available in an official release of IINA so that users intending to report this problem can easily locate this existing report. Once the fix for this issue has been included in an official release this issue will be closed.

Should you wish to confirm the fix is working and do not have the ability to build IINA from the sources in the develop branch, at some point a new unsigned nightly build will be available for download. If you encounter a defect in a nightly build that has not been reported please enter an issue for it and be sure to indicate the problem was found in a nightly build.

The ability to disable this GitHub automatic closing action has been requested by GitHub users (discussions #23476 and #17308 for example), but so far GitHub has not implemented a way to control this behavior.

[low-batt]

This is fixed in the released version of IINA.