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

[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

[jaseg]

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.

[ghost]

Should now work better.

[matoro]

Hi, I know this issue is a bit old but I think it's better than opening a new one. Could you disable resume-playback on special block devices as well? I open /dev/video0 in mpv to view my webcam, and it attempts to resume playback, of course failing, so I have to manually specify the --no-resume-playback option. Many thanks for your hard work!

[ghost]

It should already be considered unseekable (since I expect you can't seek in that device file), but I have no way to test.

[matoro]

@wm4 Unfortunately not, as you can see here:

$ mpv /dev/video0
[10052718]    cplayer: Resuming playback. This behavior can be disabled with --no-resume-playback.
[10052742]    cplayer: Loading config '/home/matoro/.config/mpv/watch_later/DE2B8D7F52F0D204CC7667A23B2A7902'
[10067932]    cplayer: Playing: /dev/video0
[10531515]    cplayer:  (+) Video --vid=1 (rawvideo)
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
[10570983]         vf: Using conversion filter.

Break with ^C

[27888967]    cplayer: Saving state.
[27896841] ffmpeg/demuxer: video4linux2,v4l2: Some buffers are still owned by the caller on close.
[27930939]     ffmpeg: ioctl(VIDIOC_QBUF): Bad file descriptor
[27931271]    cplayer: 
[27931291]    cplayer: 
[27931296]    cplayer: Exiting... (Quit)

My webcam indicator light turns on, but the video window never appears unless I pass --no-resume-playback

Configuration file: https://my.mixtape.moe/nnivfe.conf

I am happy to run patches or testing versions if it will help.

[tostr7191]

I have the same problem. Running mpv http://www.twitch.tv/some_stream and it does not start playback if it finds a previous state (which makes little sense on a stream). The stream works normally if I pass --no-resume-playback.

$ mpv --version
mpv 0.25.0 (C) 2000-2017 mpv/MPlayer/mplayer2 projects

Running Mac OS 10.12.

[mia-0]

Looks like FFmpeg’s HLS demuxer just waits around forever until the segment with the requested timestamp arrives.

[matoro]

Thanks for reopening this, but does that mean that only web streams will be looked at again? As of mpv 0.26.0 block devices still have the same problem.

[Traneptora]

FFmpeg's HLS code has had a lot of work done on it recently. Is this still a problem in 0.28.0?

[matoro]

@thebombzen Just built v0.28.0.105.gb478d2b1ce and it looks good on streams (at least binary streams, I don't have a playlist stream to test against). However issue still seems to be present with block devices. I know those are two very different cases so it may or may not be appropriate to share an issue.

[Traneptora]

I would open a separate issue reporting this problem. That one has nothing to do with streams, just detecting the seekability of a tv device.