• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[youtube-dl] Download files from youtube.com or other video platforms

This SE answer proposes options to eliminate the DTS errors. yt-dl isn't using those options
I couldn't even find where to add them to test in yt-dl code. I tried adding --external-downloader-args, but then it moaned that it couldn't use them, even though it effectively could as --hls-prefer-ffmpeg was being used (and I even tried adding --external-downloader ffmpeg, but that didn't make any difference either).

It's probably easier to just force --hls-prefer-native in the /mod/bin/youtube script for iPlayer.
 
The --...-args ... options are a bit limited for ffmpeg where the significance of options depends on their position, but that doesn't seem to be a problem here. With the 2024.04.06 desktop yt-dl and ffmpeg 5.1.4-0+deb12u1, this skips the PTS/DTS messages but I can't find any way to eliminate the Invalid timestamps ... messages without silencing the output altogether:
Code:
youtube-dl -v -f mf_akamai-1013-0 --hls-prefer-ffmpeg 'https://www.bbc.co.uk/iplayer/episode/m001z735/tokyo-vice-series-2-1-dont-ever-fing-miss' --external-downloader-args '-fflags +igndts'
 
In case anyone is trying to access actual YT with the CF youtube-dl, be aware it will fail due to a combination of YT hardening and a latent bug. The latest youtube-dl master code and nightly release solve the problem.
 
Not a user - I use yt-dlp with the Tartube front end under Windows - but few days back I noticed the highest MP4 available from YT was dropped from 1024 to 360.
 
Last edited:
That's just the best format with both video and audio. Tell youtube-dl what quality you want and, if no suitable combined format is offered, it will try to get separate video and audio streams matching your requirements and merge them with ffmpeg. Similarly, but more so, for yt-dlp; check the -S ... option.
 
Regarding https://hummy.tv/forum/threads/wip-handling-large-files-for-qtube-and-youtube-dl.11315/, some discussion from here on may be relevant.

There is extra functionality in yt-dlp (-P temp:wherever) that supports creating WIP files in a user-specified location wherever and then moving the final files to their expected location, but it would be painful to implement in youtube-dl:
Code:
    -P, --paths [TYPES:]PATH        The paths where the files should be
                                    downloaded. Specify the type of file and the
                                    path separated by a colon ":". All the same
                                    TYPES as --output are supported.
                                    Additionally, you can also provide "home"
                                    (default) and "temp" paths. All intermediary
                                    files are first downloaded to the temp path
                                    and then the final files are moved over to
                                    the home path after download is finished.
                                    This option is ignored if --output is an
                                    absolute path
(it should say "intermediate")
 
That's just the best format with both video and audio...
Advantage of being able to do a download in 720p MP4 (not 1020 as I mis-typed) was speed as no conversion was needed. Meant I could do YT downloads using an old HP laptop without having it run at 100% CPU for what seemed like hours. Even the main PC with an old I7 3770K takes minutes to transcode a 5-10 minute video to 720p with no external graphics card hardware to help out.
But I've found 360p is good enough for ephemeral stuff as the Humax does a pretty good job of upscaling.
 
Generally, there is no re-encoding when combining video and audio streams under youtube-dl (or it would not be practical on the HD/R platform). Rather, the streams are multiplexed, frame by frame, into a single container. This works fine for 480, 540, 720 resolutions; 1080+ may cause problems because of the gigantic file sizes. But any laptop that is not able to vote in Scotland should have no trouble (older laptops may need to be rebuilt with an efficient OS). Problems on such platforms can be raised in the main yt-dl issue tracker.

@BH, you may need to read the quoted post again.
 
Not a user - I use yt-dlp with the Tartube front end under Windows - but few days back I noticed the highest MP4 available from YT was dropped from 1024 to 360.
And today you can download 720p MP4 again and even higher, but not if you select MP4 and Highest as used to give a 720p download - that now gives a error.
[Edit] It was a glitch - it audio fine side but video blank. Didn't feel like checking the file properties
 
Last edited:
In case anyone is trying to access actual YT with the CF youtube-dl, be aware it will fail due to a combination of YT hardening and a latent bug. The latest youtube-dl master code and nightly release solve the problem.
And again, though the problematic JS player code that YT was sending may now have been rotated to others that don't break the previous yt-dl release code.
 
Such as this, you mean?

Code:
12/07/2024 18:55:46 - Caught error: WARNING: [youtube] Unable to decode n-parameter: download likely to be throttled (Unable to extract Initial JS player n function name; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see  https://yt-dl.org/update  on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Traceback (most recent call last):
 
I had the forbidden line as well, but you're right I was running 2023.12.07-1. I take it 2024.07.10 won't help!!
 
It seems the arms race continues:

Code:
19/07/2024 19:04:02 - Starting queued download URL https://youtu.be/jwTkLWguwQI Options  QID 9060
19/07/2024 19:05:13 - [youtube] jwTkLWguwQI: Downloading webpage
19/07/2024 19:05:16 - [youtube] jwTkLWguwQI: Downloading player d60b0ef9
19/07/2024 19:12:02 - [download] Destination: /mnt/hd2/My Video/ytdownload.mp4
19/07/2024 19:12:07 - failed: Address family not supported by protocol.
19/07/2024 19:12:07 - https://rr5---sn-cu-cgnl.googlevideo.com/videoplayback?sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Ccnr%2Cratebypass%2Cdur%2Clmt&ei=4aqaZs6bGqeBhcIPx7OMiAY&ip=86.144.119.204&spc=NO7bAU0ac7R5Fv_ITj9Kmge6yMRgeO4SVlUIFnxdj1dnSH5XXWtclMN8VGyoh5Q&id=o-AIdL6-RYIH1gFsrcAFdbPPQjNDnYee3nQAYoLJxUvHwV&txp=5319224&svpuc=1&cnr=14&xpc=EgVo2aDSNQ%3D%3D&requiressl=yes&ratebypass=yes&source=youtube&mv=m&sig=AJfQdSswRgIhAPjz2_YloGJTfjB-EKS08Nq-XaGe5HoHm8Rgj9LbRwg_AiEAhTPkXsRZW81a_qfSQ0SVp3iCqRGIRONIHLtP4dPTdh0%3D&dur=265.334&ns=03xgQXjVKS4ScQp92-qNmJkQ&initcwndbps=2155000&vprv=1&lsig=AHlkHjAwRQIhAKIpfmE56p9MzIHb_yLc9xvu4pdiV5JnooKPuHqi8YAuAiAMsI8F0jAyaAQNVlSBh69nIKdl9aBc-Pyqac_0A5Z6jQ%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lmt=1703288179453477&c=WEB&sefc=1&bui=AXc671LtlVf3RVvcSbNiNwoI-ep95Y1m1kJhqRn-iAWX9QoZgeXeR7FGQaawf0a1EuIdPGr-wcCvm4MW&mime=video%2Fmp4&fvip=3&rqh=1&itag=18&mm=31%2C29&mn=sn-cu-cgnl%2Csn-cu-auo6&mh=NM&n=VEuZqgXNQ7xs1A&mt=1721411819&expire=1721433921&pl=25&ms=au%2Crdu&mvi=5:
19/07/2024 19:12:07 - 2024-07-19 19:12:07 ERROR 404: Not Found.
19/07/2024 19:12:07 -
19/07/2024 19:12:07 -
19/07/2024 19:12:07 -
19/07/2024 19:12:08 - Caught error: ERROR: wget exited with code 8
19/07/2024 19:12:08 - -code 1 -level 0 -errorinfo {{} /mod/webif/plugin/qtube/queue.hook 29} -errorcode {CHILDSTATUS 5219 1}

What does "address family not supported by protocol" mean?
 
To diagnose this, it'll be necessary to run the yt-dl command directly. On my laptop (if you have a big lap), this command ran OK after a run in which a corrupt file was generated: as YT is now giving 403 on DASH segments more often we should now make --abort-on-unavailable-fragment the default. A suitable command:
Code:
youtube-dl -v --abort-on-unavailable-fragment --fragment-retries 3 jwTkLWguwQI
 
I guess those could be command options in qtube? Is "jwTkLWguwQI" stand-alone, or does it require a URL prefix?
 
Back
Top