player: playlist-pos now use -1 for "no entry selected"

It's odd that this state is observable, but is made implicit by making
the property unavailable. It's also odd that an API user cannot directly
put the player into such a state.

Just allow reading/writing -1 (or in fact, any out of bounds index) for
this case.

I'm also refraining from using OPT_CHOICE for the "no selection" case,
because although that would be cleaner in theory, it would cause only
problems to API users due to the more complex property type (worse is
better).

One reason for not restricting the integer range on the input property
anymore is that if there are no playlist elements, the range would
contain only 1 integer, which cannot be represented anymore since the
recent m_option change. This was actually broken with 1 element
playlists before (and still is, with the constricted type for OSD and
the add/cycle commands). Doesn't matter too much.

1 files changed, 1 insertions, 1 deletions

diff --git a/player/loadfile.c b/player/loadfile.c
index 8a8094c3e3..0ae59a0e65 100644
--- a/player/loadfile.c
+++ b/player/loadfile.c
@@ -1828,7 +1828,7 @@ void mp_set_playlist_entry(struct MPContext *mpctx, struct playlist_entry *e)
     mpctx->playlist->current_was_replaced = false;
     // Make it pick up the new entry.
     if (mpctx->stop_play != PT_QUIT)
-        mpctx->stop_play = PT_CURRENT_ENTRY;
+        mpctx->stop_play = e ? PT_CURRENT_ENTRY : PT_STOP;
     mp_wakeup_core(mpctx);
 }