Repository: yt-dlp
Issue: [YouTube Live] Resuming a download for a long livestream is broken
Labels: site-enhancement

### Checklist

- [X] I'm reporting a broken site
- [X] I've verified that I'm running yt-dlp version **2021.12.27**. ([update instructions](https://github.com/yt-dlp/yt-dlp#update))
- [X] I've checked that all provided URLs are alive and playable in a browser
- [X] I've checked that all URLs and arguments with special characters are [properly quoted or escaped](https://github.com/ytdl-org/youtube-dl#video-url-contains-an-ampersand-and-im-getting-some-strange-output-1-2839-or-v-is-not-recognized-as-an-internal-or-external-command)
- [X] I've searched the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues including closed ones. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)
- [X] I've read about [sharing account credentials](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#are-you-willing-to-share-account-details-if-needed) and I'm willing to share it if required

### Region

_No response_

### Description

When using `--live-from-start` on YouTube livestreams, if the stream is longer than than 120 hours, the download will begin at a fragment 120 hours ago instead of the initial fragment because YouTube eventually removes live fragments. (Actually YouTube does this after 168 hours so this amount could be increased but that is a separate issue.) After this point, if one tries to resume downloading a livestream that has already been partially downloaded, it will not behave properly. In many cases it will simply stall and not download any fragments. When it does download fragments, they will not be the fragments that came after the ones that were previously downloaded, even if those fragments are still available on the server.

I believe I know the reason but it's tedious to test so I apologize if I'm wrong. It seems as if the code is renumbering fragments instead of using YouTube's static `sq/N` numbering in order to skip old fragments. So, for example, if a long livestream with 1s fragments was downloaded for 6 days, 518400 fragments would be downloaded. If this download is then stopped and then immediately resumed, it will renumber the fragments in such a way that the current live fragment (Which I think is `sq/518400` because YT starts at 0 and yt-dlp starts at 1) is numbered ~432000 internally in the second instance of yt-dlp, so that the live duration of the fragments it thinks it is targeting is 120 hours. But then it tries to continue by downloading fragment 518401 in the new numbering, which is approximately `sq/604800`, a fragment that will not be live for another full day. If you do wait for that fragment to be live, it will continue from that point, but you have missed a full day worth of fragments. On the other hand, if you cancel the download after 4 days but resume after 6 days, it will download fragments immediately, but it will still grab the wrong fragments, starting at the 5 day mark instead of the 4 day mark.

Assuming I'm correct, the simplest way to fix this is to always use YouTube's internal numbering of fragments. Old fragments will still need to be skipped but this should be accomplished without renumbering so that all yt-dlp instances agree on the fragment numbers.

### Verbose log

```shell
yt-dlp211227.exe https://www.youtube.com/watch?v=Va4AzLOxCwQ -f 134 --live-from-start -o "Va4AzLOxCwQ.mp4" -Uv
[debug] Command-line config: ['https://www.youtube.com/watch?v=Va4AzLOxCwQ', '-f', '134', '--live-from-start', '-o', 'Va4AzLOxCwQ.mp4', '-Uv']
[debug] Encodings: locale cp1252, fs utf-8, out utf-8, err utf-8, pref cp1252
[debug] yt-dlp version 2021.12.27 [6223f67] (win_exe)
[debug] Python version 3.7.9 (CPython 32bit) - Windows-10-10.0.19041-SP0
[debug] exe versions: ffmpeg git-2020-07-29-cbb6ba2, ffprobe git-2020-07-29-cbb6ba2
[debug] Optional libraries: Cryptodome, mutagen, sqlite, websockets
[debug] Proxy map: {}
Latest version: 2021.12.27, Current version: 2021.12.27
yt-dlp is up to date (2021.12.27)
[debug] [youtube] Extracting URL: https://www.youtube.com/watch?v=Va4AzLOxCwQ
[youtube] Va4AzLOxCwQ: Downloading webpage
[youtube] Va4AzLOxCwQ: Downloading android player API JSON
[youtube] Va4AzLOxCwQ: Downloading MPD manifest
[youtube] Va4AzLOxCwQ: Downloading MPD manifest
[debug] Sort order given by extractor: quality, res, fps, hdr:12, source, codec:vp9.2, lang, proto
[debug] Formats sorted by: hasvid, ie_pref, quality, res, fps, hdr:12(7), source, vcodec:vp9.2(10), acodec, lang, proto, filesize, fs_approx, tbr, vbr, abr, asr, vext, aext, hasaud, id
[info] Va4AzLOxCwQ: Downloading 1 format(s): 134
[debug] Invoking downloader on "https://manifest.googlevideo.com/api/manifest/dash/expire/1642670607/ei/..."
[dashsegments] Total fragments: unknown (live)
[download] Destination: Va4AzLOxCwQ.mp4
WARNING: [youtube] Starting download from the last 120 hours of the live stream since YouTube does not have data before that. If you think this is wrong, please report this issue on  https://github.com/yt-dlp/yt-dlp . Make sure you are using the latest version; type  yt-dlp -U  to update. Be sure to call yt-dlp with the --verbose flag and include its complete output.

(Code was allowed to run for several minutes, attempting to continue a download that had been going for over 5 days. The above is the entire verbose output.)
```