Don't try "resume-playback", if not seekable #1701

Closed
klausenbusk opened this Issue Mar 18, 2015 · 2 comments

Projects

None yet

3 participants

@klausenbusk

Hello

The --save-position-on-quit is really useful, but when you also often listen to live streams it kind of annoying that you need to specific --no-resume-playback every time.. When MPV just could check if it is seekable, and if not just play it..

Regards Kristian

@wm4 wm4 added a commit that closed this issue Mar 18, 2015
@wm4 wm4 player: refuse to write resume file with unseekable files
In fact this should happen on resume, not on saving, but it's simpler
this way.

Fixes #1701.
39ed9b7
@wm4 wm4 closed this in 39ed9b7 Mar 18, 2015
@jaseg
Contributor
jaseg commented Sep 26, 2016

It doesn't seem 39eb9b7 really fixes this. As far as I can tell mpv is still saving playback state at least on the following streams URLs:

http://www.radioswissjazz.ch/live/aacp.m3u
http://www.deutschlandradio.de/streaming/dlf.m3u

mpv -v output here. I'm running mpv 0.18.1.

I'm not 100% sure that's not just two borked streams but even then IMHO this would be kind of glitchy behavior since when mpv tries to restore the playback position on the first URL above it will just hang indefinitely.

@wm4 wm4 added a commit that referenced this issue Sep 26, 2016
@wm4 wm4 stream_lavf: fix determining seekability
demux_lavf.c forces seek to being determined as supported if
STREAM_CTRL_HAS_AVSEEK is returned as success. But it always succeeds
with current FFmpeg versions. (Seems like Libav commit cae448cf broke
this in early 2016.)

Now we can't determine via private API whether the underlying protocol
supports read_seek anymore. The affected protocols (mostly rtmp) also
set seekable=0, meaning they signal they're not seekable, even though
read_seek would work. (My guess is that this can't be fixed because even
though seekable is in theory a combination of elaborate flags [of which
only 1 is defined, AVIO_SEEKABLE_NORMAL], a seekable!=0 always means
it's byte-seekable in some way.)

So the FFmpeg API is being garbage _again_, and all what we can do is
determining this via protocol name and a whitelist.

Should fix the behavior reported in #1701.
0f110ad
@wm4
Member
wm4 commented Sep 26, 2016

Should now work better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment