mpv-reload icon indicating copy to clipboard operation
mpv-reload copied to clipboard

Youtube session invalidation - simply exits instead of reloading

Open Farzat07 opened this issue 4 years ago • 11 comments

When a youtube video is left paused in mpv for a long time, the session becomes invalidated (naturally). However, when resumed and the cached amount is consumed, mpv simply exits as it thinks the EOF has been reached. The expected behaviour would be to reload the video from its original url.

The following error messages are the only ones which appear after the youtube session has been invalidated:

[ffmpeg] https: HTTP error 403 Forbidden
[ffmpeg] tls: The specified session has been invalidated for some reason.
[ffmpeg] https: Will reconnect at 95321392 in X second(s), error=Input/output error.

where X takes the value of 0, 1, 3, and 7.

Farzat07 avatar Nov 24 '21 07:11 Farzat07

@Farzat07 thanks for reporting, I'll try to reproduce this issue. How long do I need to wait until the cache invalidation happens?

4e6 avatar Nov 25 '21 11:11 4e6

I never really measured the time, but I guess around 6 hours should be enough.

Farzat07 avatar Nov 27 '21 09:11 Farzat07

Ugh, it'll take some time to reproduce. BTW, after reading the issue again

... mpv simply exits as it thinks the EOF has been reached.

The plugin has an option to check for more content after the EOF is reached. But it is disabled by default.

# when the end-of-file is reached, reload the stream to check
# if there is more content available.
reload_eof_enabled=no

Maybe try enabling it and see if that helps.

4e6 avatar Nov 29 '21 09:11 4e6

Yeah but I believe that is supposed to be for different use cases e.g. a live stream. When used on normal videos that setting makes mpv kinda enter into an infinite loop at the end of the video.

Farzat07 avatar Nov 29 '21 11:11 Farzat07

mpv kinda enter into an infinite loop at the end of the video

Hmm... it does not happen to me, at least with YouTube videos. Can use send a link that triggers this behavior when played with mpv?

4e6 avatar Nov 29 '21 13:11 4e6

Ok I was wrong actually - it does not actually get into a loop, but it does get stuck at the ending which makes it seem like so. At the EOF the video reloads and as there is nothing left to play, the video just stays as it is. If you go back 5 seconds, it plays them again with distorteed voice and then exits.

I'm finding this behaviour consistent across videos, even local ones. You can reproduce with this one https://videos.lukesmith.xyz/w/jNDH1cnxNfwwJH2pZvAqdM. The only exception was youtube though - it just exited normally after discovering that this is actually the end of the file.

In the end this setting seems to effectively mimic the --keep-open option as a side effect (at least in the majority of cases). It might work as a temporary solution but I don't think it is ideal.

Farzat07 avatar Nov 29 '21 15:11 Farzat07

I'm trying to check the link. youtube-dl does not recognize the file format, are you using a different backend?

$ mpv 'https://videos.lukesmith.xyz/w/jNDH1cnxNfwwJH2pZvAqdM'
Failed to recognize file format.
$ youtube-dl -F 'https://videos.lukesmith.xyz/w/jNDH1cnxNfwwJH2pZvAqdM'
[generic] jNDH1cnxNfwwJH2pZvAqdM: Requesting header
WARNING: Falling back on generic information extractor.
[generic] jNDH1cnxNfwwJH2pZvAqdM: Downloading webpage
[generic] jNDH1cnxNfwwJH2pZvAqdM: Extracting information
[info] Available formats for jNDH1cnxNfwwJH2pZvAqdM:
format code  extension      resolution note
0            unknown_video  unknown

4e6 avatar Nov 30 '21 14:11 4e6

Yeah I'm using yt-dlp because they applied the fix to that (peertube links).

You can use this static link though, same effect.

https://videos.lukesmith.xyz/static/webseed/9847f270-f9ab-42ff-8d33-a59da419b245-480.mp4

Farzat07 avatar Nov 30 '21 15:11 Farzat07

Hmm... For me, the video doesn't get stuck or get into a loop. On EOF it reloads and then exits.

$ mpv 'https://videos.lukesmith.xyz/static/webseed/9847f270-f9ab-42ff-8d33-a59da419b245-480.mp4'
 (+) Video --vid=1 (*) (h264 852x480 24.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
Cannot load libcuda.so.1
AO: [pulse] 44100Hz stereo 2ch float
VO: [gpu] 852x480 => 853x480 yuv420p
AV: 00:09:32 / 00:09:32 (100%) A-V:  0.000 Cache: 0.0s
[reload] eof reached, checking if more content available
[reload] reloading video from 572.232562 second
[reload] file  1 of 1 in playlist

AV: 00:09:32 / 00:09:32 (100%) A-V:  0.000 Cache: 0.0s
 (+) Video --vid=1 (*) (h264 852x480 24.000fps)
 (+) Audio --aid=1 (*) (aac 2ch 44100Hz)
AV: 00:09:32 / 00:09:32 (100%) A-V:  0.000 Cache: 0.0s
[reload] eof reached, playback ended

Exiting... (End of file)

I'm using the default youtube-dl script. Can it be an issue with how the reload plugin interacts with yt-dlp?

4e6 avatar Dec 01 '21 11:12 4e6

Ok I tried the original youtube-dl backend, same problem.

But then I tried changing my configuration to see if one of my settings was causing this: turns out the culprit is gapless-audio=no. Once I comment that line, the error disappears.

I still need that setting though - without it replaygain settings can't be used on playlists (check https://github.com/mpv-player/mpv/issues/8267).

Farzat07 avatar Dec 02 '21 03:12 Farzat07

gapless-audio setting has no effect to me. From the man page

     NOTE:
        This feature is implemented in a simple manner  and  relies  on  audio  output  device
        buffering  to  continue playback while moving from one file to another. If playback of
        the new file starts slowly, for example because it is played from a remote network lo‐
        cation  or because you have specified cache settings that require time for the initial
        cache fill, then the buffered audio may run out before playback of the  new  file  can
        start.

I assume it has something to do with the latency, maybe I wasn't lucky enough. Anyway, I'll try to reproduce the original issue with the timed-out YouTube session.

4e6 avatar Dec 03 '21 13:12 4e6