summaryrefslogtreecommitdiffstats
path: root/player/playloop.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2016-06-08 11:59:11 +0200
committerwm4 <wm4@nowhere>2016-06-08 12:02:06 +0200
commitbd9bba40ee8e2d11ecfa987b744667dc221870d3 (patch)
treec5b6d066faa7e87d8b19a01264fe9c66bb70d6f1 /player/playloop.c
parentaeb3df0e2c7f8e86f7b550f876dc24ae1c4686f6 (diff)
downloadmpv-bd9bba40ee8e2d11ecfa987b744667dc221870d3.tar.bz2
mpv-bd9bba40ee8e2d11ecfa987b744667dc221870d3.tar.xz
player: tell user about --force-seeking if demuxer is not seekable
This comes up often, see e.g. #3220. The issue is that if the stream input is not seekable, the demuxer is marked as not seekable. But if the stream cache is enabled, the file still _might_ be seekable to a degree. We recently disabled seeking in this mode because it can cause very weird issues, mostly because if stream-layer seeking fails, the demuxers will arbitrarily misbehave. On the other hand, it can work if the seek is within the cached range, which is why the user can still enable it with --force-seeking. There is a weird trade-off between allowing this and not crapping up too easily, so just informing the user about the possibility seems best.
Diffstat (limited to 'player/playloop.c')
-rw-r--r--player/playloop.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/player/playloop.c b/player/playloop.c
index 56701dbc34..87acfe3cc7 100644
--- a/player/playloop.c
+++ b/player/playloop.c
@@ -189,7 +189,8 @@ static int mp_seek(MPContext *mpctx, struct seek_params seek)
return -1;
if (!mpctx->demuxer->seekable) {
- MP_ERR(mpctx, "Can't seek in this file.\n");
+ MP_ERR(mpctx, "Cannot seek in this file.\n");
+ MP_ERR(mpctx, "You can forcibly enable it with '--force-seeking=yes'.\n");
return -1;
}