summaryrefslogtreecommitdiffstats
path: root/player/loadfile.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2019-12-06 19:21:14 +0100
committerwm4 <wm4@nowhere>2019-12-06 19:21:14 +0100
commitb0c9f582adb4caac06c567ba1546f5773792bb14 (patch)
treec751bd48d852e4894204d01759f146191a76e0af /player/loadfile.c
parent13fe87f66b2cb38dda2dd1502cd4930f8a5fc801 (diff)
downloadmpv-b0c9f582adb4caac06c567ba1546f5773792bb14.tar.bz2
mpv-b0c9f582adb4caac06c567ba1546f5773792bb14.tar.xz
player: loadfile overrides previous stop command
Both the "stop" and "loadfile" commands are asynchronous. "stop" starts terminating playback, which used to be done in the same playloop iteration, but now it may take longer, so a "loadfile" command can be received while this is going on. (Possible that it used to work if the second command was issued at least in the next playloop iteration.) Make the "loadfile" override the "stop" mode, so the next file will be played, instead of quitting or going into idle mode. Unlike the referenced bug report claims, this has nothing to do with IPC. Fixes: #7225
Diffstat (limited to 'player/loadfile.c')
-rw-r--r--player/loadfile.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/player/loadfile.c b/player/loadfile.c
index 603b264f60..2535e75617 100644
--- a/player/loadfile.c
+++ b/player/loadfile.c
@@ -1830,7 +1830,7 @@ void mp_set_playlist_entry(struct MPContext *mpctx, struct playlist_entry *e)
mpctx->playlist->current = e;
mpctx->playlist->current_was_replaced = false;
// Make it pick up the new entry.
- if (!mpctx->stop_play)
+ if (mpctx->stop_play != PT_QUIT)
mpctx->stop_play = PT_CURRENT_ENTRY;
mp_wakeup_core(mpctx);
}