command: change cycle-value command behavior

Instead of using an internal counter to keep track of the value that was
set last, attempt to find the current value of the property/option in
the value list, and then set the next value in the list.

There are some potential problems. If a property refuses to accept a
specific value, the cycle-values command will fail, and start from the
same position again. It can't know that it's supposed to skip the next
value. The same can happen to properties which behave "strangely", such
as the "aspect" property, which will return the current aspect if you
write "-1" to it. As a consequence, cycle-values can appear to get
"stuck".

I still think the new behavior is what users expect more, and which is
generally more useful. We won't restore the ability to get the old
behavior, unless we decide to revert this commit entirely.

Fixes #5772, and hopefully other complaints.

1 files changed, 2 insertions, 0 deletions

diff --git a/DOCS/interface-changes.rst b/DOCS/interface-changes.rst
index d9fa295fc4..a21f50e0fa 100644
--- a/DOCS/interface-changes.rst
+++ b/DOCS/interface-changes.rst
@@ -98,6 +98,8 @@ Interface changes
       nobody wants to fix it. Automatic 3D down-conversion to 2D is also broken,
       although you can just insert the stereo3d filter manually. The obscurity
       of 3D content doesn't justify such an option anyway.
+    - change cycle-values command to use the current value, instead of an
+      internal counter that remembered the current position.
  --- mpv 0.28.0 ---
     - rename --hwdec=mediacodec option to mediacodec-copy, to reflect
       conventions followed by other hardware video decoding APIs