My download is at 3852.2%
GiakomoZ opened this issue · comments
Describe the bug
After updating to yt-dlp 2023.06.22, I tried downloading a video but apparently the download goes crazy at 3852.2% and stops after a bunch of seconds leaving 3 .PART files. It does like this with every vid I try to download.
To Reproduce
I don't know, just try to download the same video i guess.
Screenshots
Additional info:
- OS: Windows 11
- Application version 2.4.8
Additional context
All the videos I try to download were at the max resolution possible, but I think this doesn't matter
Seeing the same issue - no common factor among videos, and it's affecting some very similar to ones I've downloaded before with no incident:
Also, unlike the OP, I'm actually succeeding in downloading the videos, but when I try to use my default video player to view them I'm getting blocked by an error message I've never seen before. Should I go into more detail here or open up a separate issue for that?
may be related: i'm on a mac and before yt-dlp updated, this fork knew to download using AVC1 for video and AAC for audio because quicktime on macOS doesn't support VP9 or opus (i always download videos in MP4).
i downloaded a video today, and upon updating yt-dlp, the video codec defaulted to VP9 (audio still downloaded in AAC). opening the file in quicktime didn't show the video, only audio.
i also got a super high percentage while downloading. log file was counting percentage the way it should've been.
however, when i turned on "show available codecs" in settings and selected AVC1 for video, the count displayed normally and i was able to open the file in quicktime without error.
no errors on yt-dlp or OVD's end either way.
idk how VP9 download was before yt-dlp updated, but i haven't seen OVD display an extreme percentage either.
Just also tried on my machine and the progress bar froze but the download continued in the background. What I first thought has happened is that there are now more log lines / progress updates than before, which would also explain #59 - but that video download produced about 6.000 log lines which is still reasonable in my opinion. Not sure.
ok just investigated the log lines, and what is displayed actually matches up to what yt-dlp is printing out:
[download] 214.6% 598.31KiB/s 00:00 {"status": "downloading", "downloaded_bytes": 105408, "fragment_index": 1, "fragment_count": 138, "filename": "C:\\Users\\Stefan\\Downloads\\Rubik's Cube World Record after 5 YEARS \uff5c Max Park 3.13 seconds-(480p30).f606.mp4", "tmpfilename": "C:\\Users\\Stefan\\Downloads\\Rubik's Cube World Record after 5 YEARS \uff5c Max Park 3.13 seconds-(480p30).f606.mp4.part", "max_progress": null, "progress_idx": null, "elapsed": 0.2706568241119385, "total_bytes_estimate": 49128.0, "speed": 612670.7400766246, "eta": 0, "_eta_str": "00:00", "_speed_str": " 598.31KiB/s", "_percent_str": "214.6%", "_total_bytes_str": " N/A", "_total_bytes_estimate_str": " 47.98KiB", "_downloaded_bytes_str": " 102.94KiB", "_elapsed_str": "00:00:00", "_default_template": "214.6% of ~ 47.98KiB at 598.31KiB/s ETA 00:00 (frag 1/138)"}
For example in the above line the progress is at 214%
"_percent_str": "214.6%"
Let me check if yt-dlp is already aware
may be related: i'm on a mac and before yt-dlp updated, this fork knew to download using AVC1 for video and AAC for audio because quicktime on macOS doesn't support VP9 or opus (i always download videos in MP4).
i downloaded a video today, and upon updating yt-dlp, the video codec defaulted to VP9 (audio still downloaded in AAC). opening the file in quicktime didn't show the video, only audio.
i also got a super high percentage while downloading. log file was counting percentage the way it should've been.
however, when i turned on "show available codecs" in settings and selected AVC1 for video, the count displayed normally and i was able to open the file in quicktime without error.
no errors on yt-dlp or OVD's end either way.
idk how VP9 download was before yt-dlp updated, but i haven't seen OVD display an extreme percentage either.
So is there a way to identify what the codec it's automatically selecting is? I've definitely seen the same thing where some videos have the above-100 percentage count and are subsequently unplayable (at least by my preferred video player), and some don't and are. But I'm not on a Mac so I doubt it's the same as you.
So is there a way to identify what the codec it's automatically selecting is?
i don't think there is
Let me check if yt-dlp is already aware
did not see an issue on their repository, but when I attempted to reproduce with the CLI the output was always fine, so it might be caused by some parameter.
Let me check if yt-dlp is already aware
did not see an issue on their repository, but when I attempted to reproduce with the CLI the output was always fine, so it might be caused by some parameter.
Is there a way to reset the yt-dlp config?
Any progress towards fixing this? Having to figure out the correct codec for each video (because it hasn't actually always been the same) is a noticeable level of added tediousness of the kind I use a GUI specifically to avoid.
It will be a more long term rewrite to fix this - if you really need a workaround you can manually switch back to an older yt-dlp version and disable the auto update for now
Okay, so how do I do that? The obvious solution of deleting the yt-dlp.exe file and downloading one from an earlier release does not seem to be working as it's still producing nonsensical size estimates that are a clear sign of trying to use the bad codecs.
I See - I assumed that yt-dlp changed something in the YouTube extractor, but if you can also reproduce with older versions it means that YouTube changed something about the video versions they are offering.
So it is a bit of a harder issue to solve. If you can figure out which format sorting we could apply then I think we can just hardcode a sorting that prefers the versions you want https://github.com/yt-dlp/yt-dlp#sorting-formats
, otherwise I will need some time to find a good way to expose sorting to the user
Seems to only affect downloading videos from YouTube.
If anyone happens to also use the FreeTube app on Desktop, that app's video downloader seems too work fine, so that might be a good backup option until YT-DLP resolves this.
I think with the latest YT-DLP hotfix it's safe to say this issue is resolved?
nope, still getting high percentages and downloading in VP9 by default. OVD probably needs an update too tho
I think with the latest YT-DLP hotfix it's safe to say this issue is resolved?
I mean, yesterday I tried download g some vids and they worked, but for a good half of them the progress bar is still broken...
I mean, yesterday I tried download g some vids and they worked, but for a good half of them the progress bar is still broken...
same here. downloaded three vids, only one worked as intended.
i also noticed the size it calculates is wrong sometimes:
- 4½ minutes of 1080p30 video came out as 4.1 MB, progress bar high percentage, video output in VP9
- 27½ minutes of 1080p30 video was about 300 MB, progress bar functioned as normal, video output in AVC1
of course, having a mac, i'm the special case here lol
I've migrated to using this program instead for most video downloads. The Lobbenmeier app is better for handling playlist URLs, but I've yet to encounter this bug with the other app.
I've had this experience too with a bunch of downloads just did - Patreon private 1080p30 Youtube. It might depend in the backend codec Youtube is offering. Mediainfo shows them all to be vp9.
What yt-dlp seems to be doing underneath is quickly downloading a small file and then downloading the video content in individual fragments which it then reassembles into a whole at the end. The GUI does update progress while downloading the small file at the start but then sits showing strange >100% values then ceases to update showing progress as all the individual fragments download jobs tick through - I could see the individually numbered fragNNN files appearing and disappearing in an Explorer window. Then it writes out the assembled fragments into a single video file and the GUI updates progress normally while downloading the single audio file and then merging them into the final resulting download.
So it all still 'works' (i.e. the underlying download succeeds), but the changes to how yt-dlp is going about downloading video - using individually sized multiple fragment downloads - confuses the GUI which doesn't offer any accurate progress during that part of the video download phase before coming right at the end.