|author||wm4 <wm4@nowhere>||2018-02-21 17:02:18 +0100|
|committer||Kevin Mitchell <firstname.lastname@example.org>||2018-02-21 22:57:39 -0800|
stream_file: add mode for reading appended files
Do this because retrying reading on higher levels (like the demuxer) usually causes tons of problems. A hack like this is simpler and could allow to remove some of the higher level retry behavior. This works by trying to detect whether the file is appended. If we reach EOF, check if the file size changed compared to the initial value. If it did, it means the file was appended at least once, and we set the p->appending flag. If that flag is set, we simply retry reading more data every time we encounter EOF. The only way to do this is polling, and we poll for at most 10 times, after waiting for 200ms every time.
Diffstat (limited to 'DOCS')
1 files changed, 13 insertions, 0 deletions
diff --git a/DOCS/man/mpv.rst b/DOCS/man/mpv.rst
index ec68d9a9da..5ce5d43e25 100644
@@ -803,6 +803,19 @@ PROTOCOLS
``PATH`` itself should start with a third ``/`` to make the path an
+ Play a local file, but assume it's being appended to. This is useful for
+ example for files that are currently being downloaded to disk. This will
+ block playback, and stop playback only if no new data was appended after
+ a timeout of about 2 seconds.
+ Using this is still a bit of a bad idea, because there is no way to detect
+ if a file is actually being appended, or if it's still written. If you're
+ trying to play the output of some program, consider using a pipe
+ (``something | mpv -``). If it really has to be a file on disk, use tail to
+ make it wait forever, e.g. ``tail -f -c +0 file.mkv | mpv -``.
Read data from the given file descriptor (for example 123). This is similar