diff options
| author | wm4 <wm4@nowhere> | 2019-12-06 19:21:14 +0100 |
|---|---|---|
| committer | wm4 <wm4@nowhere> | 2019-12-06 19:21:14 +0100 |
| commit | b0c9f582adb4caac06c567ba1546f5773792bb14 (patch) | |
| tree | c751bd48d852e4894204d01759f146191a76e0af | |
| parent | 13fe87f66b2cb38dda2dd1502cd4930f8a5fc801 (diff) | |
| download | mpv-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
| -rw-r--r-- | player/loadfile.c | 2 |
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); } |