Safeguard to always resurrect playhead after mishaps

[forthrin]

Expected behavior of the wanted feature

I now have the solution to #11560, which will be particularly useful since it seems #17277 and friends will never be fixed.

1. Rewrite the current playhead to the file watch_later/last every time encountering keyframe.
2. Introduce a keystroke that sets the playhead to the contents of this file.

This will resolve loss of playhead position when mpv is unintentionally closed, ie. crashes or when opening another file by mistake, and the playhead is not saved. Then you just restart, press the key, and you're back were things went awry.

Alternative behavior of the wanted feature

One could also write the playhead position to one watch file per file, but that will make for a lot of files on a regular basis, and you very rarely will need to resurrect the playhead position for files before the previous one. (Though it could happen if you eg. press >twice.)

Log File

N/A

Sample Files

N/A

[guidocella]

This is already done by https://github.com/AN3223/dotfiles/blob/master/.config/mpv/scripts/auto-save-state.lua or https://gist.github.com/Hakkin/5489e511bd6c8068a0fc09304c9c5a82.

[forthrin]

Thanks for the pointers! I found an even better solution in the meantime.

If mpv forks itself on startup and continues as a child process, the parent process can capture the exit status even after the most horrendous crash and save this to eg. ~/.config/mpv/status.

Then Lua/mpv can on startup check previous exit status in this file, and if it was uncalled for, auto-set the last known playhead (from eg. ~/.config/mpv/head). No need for manual keypresses.

So unless someone has an even better idea, the feature request is now having mpv spawn a child process, and save the exit status to disk for future decision-making.

[guidocella]

You can do this in a script with the end-file event.

[forthrin]

1. Will this event run even after cataclysmic crashes? (ie. does mpv already run as a fork?)
2. mpv actually returns zero on the FFmpeg bug. Any reason, or oversight to be fixed as non-zero?

[guidocella]

1. Will this event run even after cataclysmic crashes? (ie. does mpv already run as a fork?)

No, but you can simply delete the status file on startup and assume it crashed if the file wasn't written. Or use a wrapper shell script.

2. mpv actually returns zero on the FFmpeg bug. Any reason, or oversight to be fixed as non-zero?

I don't know what the FFmpeg bug consists of.

[forthrin]

1. Good point. I know the technique, just didn't think of it amow.
2. Help on eliminating frequent mpv crashes related to HLS and DNS #17277. Do you know why they won't fix it, or know someone who can?

Do you think a video should always continue after a crash, so that this should be an integrated feature, rather than a plugin?

PS! A keypress will be necessary if the problem was that the user eg. opened a new video by mistake, as mpv obviously can't know that this was unintended.

[guidocella]

I meant I have no idea about the details of that bug. Though the manual states "playback of a file is considered to be successful if initialization was mostly successful, even if playback fails immediately after initialization." so returning status code 0 would be expected.

I don't think it should be an integrated feature because ideally crashes should be fixed instead, and the scripts I linked already handle it. You can open the watch later menu after restarting mpv and continue from the first entry.

When opening a new file from a file explorer, mpv opens a new window. I don't know why it's different on macOS but check if you configure it.

[forthrin]

1. Underlying rationales for returning 0 on non-init failures?
2. Your point validly deduces that each playhead loss should be solved separately.

A) User mistakes: Plugin (or built-in)
B) mpv crashes: The team fixes crashes quickly, so your point holds
C) Dependency crashes: Severe, eg. a crash every 5 minutes not fixed for years.

So the best fix is writing a plugin that restores the playhead if mpv.log contains /ffmpeg.*failed too many times/?

[guidocella]

1. Underlying rationales for returning 0 on non-init failures?

No idea. It can probably be changed.

C) Dependency crashes: Severe, eg. a crash every 5 minutes not fixed for years.

So the best fix is writing a plugin that restores the playhead if mpv.log contains /ffmpeg.*failed too many times/?

What is wrong with the scripts to periodically save watch later and restarting from the first entry in the watch later menu?

[kasper93]

This is conflict of interest of saving playback state and current usecases that some people depend on. Basically speaking, it would be quite natural to keep saved position valid throughout the playback, but even when I proposed to not remove saved state on playback start it was rejected.

Currently when playback start the saved state is removed and only saved when explicitly requested or the player is closed without any issues or interruption. It's very limiting, in the sense that, one of the viable usecases to restoring playback state is to continue after interruption, but this is not possible currently.

[forthrin]

Restarting needs to be fully automatic when the crash happens every five minutes(!) Why not a single FFmpeg dev would fix such a severe issue for years -- nor listen to mpv devs for any issue, as someone said -- seems beyond anyone.

Anyway, wrote a Ruby wrapper that works quite well, at least for issues here. Can post it here when cleaned up, to see if it gives some pointers to how this can be integrated somehow without disturbing existing habits and functionality.

[guidocella]

It is still not clear to me if by crash you mean that the bug actually crashes mpv or just stops playback of the current file.

If you just need to refresh the current file, you can just do what the new ctrl+r keybinding does. The on_unload hook should have time-pos still available.

[forthrin]

Didn't know about ^r! Ran mpv --keep-open=yes to try, because yes, mpv doesn't crash (sorry about the misnomer)

However, here ran into another problem. Should this be reported as a separate issue? Here are the essentials:

# FINDS youtube-dl THE FIRST TIME
[v][ytdl_hook] Found youtube-dl at: ~/.config/mpv/yt-dlp

# THE FFMPEG NIGHTMARE
[e][ffmpeg] tcp: Failed to resolve hostname <host>: nodename nor servname provided, or not known
[v][lavf] EOF reached.
[w][lavf] Leaking 118 nested connections (FFmpeg bug).
[w][lavf] Leaking 118 nested connections (FFmpeg bug).

# USER PRESSES ^r, mpv FAILS TO RELAUNCH youtube-dl THIS SECOND TIME
[d][global] state path: 'watch_later' -> '~/.config/mpv/watch_later'
[v][ffmpeg] Opening <url>
[v][lavf] No format found, try lowering probescore or forcing the format.
[v][ytdl_hook] Starting subprocess: [~/.config/mpv/yt-dlp, --no-warnings, -J, --flat-playlist, --sub-format, ass/srt/best, --sub-langs, all, --write-srt, --no-playlist, --, <url>]
[e][ytdl_hook] Subprocess failed: init
[v][ytdl_hook] status: -3
[v][ytdl_hook] stdout:
[v][ytdl_hook] stderr:
[e][ytdl_hook] youtube-dl failed: not found or not enough permissions