mpv is stuck at `cplayer: video_output_image: r=3/eof=0/st=syncing` after restoring position of a live stream

Not Important Information

mpv version: b670387

Reproduction steps

1. ffmpeg -f lavfi -i testsrc -f flv -listen 1 rtmp://127.0.0.1:1935/mpv/sucks
2. mpv --no-config --start=0 rtmp://127.0.0.1:1935/mpv/sucks

The steps above are to illustrate nominal case when watch-later-options is used, position is saved and could not be restored on next run. Any seek position will hang the player.

I've seen this too with HLS, where playback would not start. But I don't have good way to reproduce that, so the above STR is a good start. HLS playback can be restored by jumping forward/backwards. But underlying issue is the same, restoring start position that is not available. So either mpv should not save position of live streams (I know it does that for unseekable streams, but apparently those are seekable) or handle when it fails to restore it instead of freezing.

Expected behavior

mpv works.

Actual behavior

mpv doesn't work.

Log file

[   0.111][v][cplayer] Starting playback...
[   0.111][v][lavf] queuing seek to 0.000000
[   0.111][v][lavf] execute seek (to 0.000000 flags 32)
[   0.111][v][cplayer] hr-seek, skipping to 0.000000
[   0.112][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.112][t][ffmpeg] rtmp: Seek on stream index 0 at timestamp 0 with flags 00000001
[   0.112][t][ffmpeg] rtmp: Sending seek command for timestamp 0
[   0.112][t][lavf] mp_seek(000001f2e3ad1220, 0, cur)
[   0.112][t][ffmpeg] seek request from 228685 to 228685
[   0.112][v][lavf] seek done
[   0.112][t][lavf] bytes=0, read_more=1 prefetch_more=0, refresh_more=0
[   0.112][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.112][d][cplayer] Run command: change-list, flags=64, args=[name="shared-script-properties", operation="append", value="osc-margins=0.000000,0.000000,0.000000,0.000000"]
[   0.112][v][cplayer] Set property: shared-script-properties -> 1
[   0.112][v][cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"r":0,"t":0} -> 1
[   0.112][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.142][t][osc] rendering 
[   0.142][d][osc] osc_init 
[   0.142][d][cplayer] Run command: change-list, flags=64, args=[name="shared-script-properties", operation="append", value="osc-margins=0.000000,0.000000,0.000000,0.000000"]
[   0.142][v][cplayer] Set property: shared-script-properties -> 1
[   0.142][v][cplayer] Set property: user-data/osc/margins={"b":0,"l":0,"r":0,"t":0} -> 1
[   0.142][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.161][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.162][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.177][t][ffmpeg] rtmp: Sending bytes read report
[   0.363][t][cplayer] video_output_image: r=3/eof=0/st=syncing
[   0.364][t][ffmpeg] rtmp: Sending bytes read report
[   0.554][t][ffmpeg] rtmp: Sending bytes read report
[   0.622][t][cplayer] video_output_image: r=3/eof=0/st=syncing
<repeats this endlessly>

Start by reproducing the RTMP case with the ffmpeg and mpv commands in the issue, then trace watch-later position restoration and the seek path shown in the log. Done means restoring a saved position on the live stream no longer leaves mpv stuck; investigate the reported HLS behavior if the same path applies.