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

You're panicking, and not considering whatever's wrong might be just finger trouble / operator error.
 
Ian Manning said:
Are there any up-to-date instructions for how to install the youtube-dl package? It's not listed in the "Available" list in the web IF, and the instructions from Github give this error:
Code: 
humax# wget https://yt-dl.org/downloads/latest/youtube-dl -O /usr/local/bin/youtube-dl
wget: not an http or ftp url: https://yt-dl.org/downloads/latest/youtube-dl
Click to expand...

This should work if the wget package is installed (ie using /mod/bin/wget). The Busybox wget (/bin/wget) in the firmware image doesn't handle HTTPS. Because of the way the download site is configured, http://yt-dl.org/downloads/latest/youtube-dl redirects to the same secure link and fails in the same way.
 
/df said:
This should work if the wget package is installed (ie using /mod/bin/wget). The Busybox wget (/bin/wget) in the firmware image doesn't handle HTTPS. Because of the way the download site is configured, http://yt-dl.org/downloads/latest/youtube-dl redirects to the same secure link and fails in the same way.
Click to expand...
Thanks - I managed to find it in the "Available" list of the web IF after following Black Hole's advice and turning on the "Advanced" option
 
When I set the media_set to iptv-uhd in youtube-dl, I get UHD content listed, BUT the files are either "audio only" or "video only". Anyone have any idea on why this is happening? Is the common practice to tell youtube-dl to merge audio+video?
 
Last edited:
It is not unusual for video and audio steams to be provided separately, otherwise the number of files required to support multiple video standards and multiple audio standards explodes.
 
yt-dl by default merges (using ffmpeg) the best video-only stream with the best audio-only stream, or gets the best combined AV stream if either of those is not available. This can be overridden with -f .../--format ...: review Format Selection in the manual.

Incidentally, @prpr, breaking YT changes mean that a new patch release of the package here would be good, and would also test that I haven't broken anything for the ancient Python that it has to use.
 
/df said:
Incidentally, @prpr, breaking YT changes mean that a new patch release of the package here would be good, and would also test that I haven't broken anything for the ancient Python that it has to use.
Click to expand...
It's been on my mind, as I do read the update logs, even if I don't understand most of it.
 
I see you did another update yesterday, but testing the other day I found it was trying to use a different nsig every single time, even when re-downloading what I'd just downloaded and deleted. This meant roughly 11 minutes of tedium before it even tried downloading any media, which then went at the speed expected.
 
The player JSON from which we run the code to descramble the nsig is supposed to be cached. Specific descrambled nsigs are cached during any yt-dl run. The player cache can be specified with this option which is accurately documented:
Code: 
--cache-dir DIR
              Location in the filesystem where youtube-dl can store some down‐
              loaded      information      permanently.       By       default
              $XDG_CACHE_HOME/youtube-dl  or ~/.cache/youtube-dl . ...
So, since ~ is RO, export XDG_CACHE_HOME=/mod/var/cache ?

This seems familiar: wasn't this discussed before? Yes, post #552, so perhaps that isn't the fix that's needed.
 
It's not player cache like before. Here's the output from the latest build a couple of days ago:
Code: 
humax# youtube -v https://www.youtube.com/watch?v=fBKScHaUo2I
[debug] System config: [u'--restrict-filenames', u'--prefer-ffmpeg', u'-f', u'best[height<=?1080][fps<=?60]', u'-o', u'/mnt/hd2
/My Video/%(title)s.%(ext)s']
[debug] User config: []
[debug] Custom config: []
[debug] Command-line args: [u'--external-downloader', u'wget', u'--hls-prefer-native', u'--cache-dir', u'/mod/.cache/youtube-dl
', u'-v', u'https://www.youtube.com/watch?v=fBKScHaUo2I']
[debug] Encodings: locale ASCII, fs ASCII, out ASCII, pref ASCII
[debug] youtube-dl version 2023.07.05
[debug] Python 2.7.1 (CPython 7405b0-smp 32bit) - Linux-2.6.18-7.1-7405b0-smp-with-libc0 - OpenSSL 1.0.0a 1 Jun 2010 - libc 0
[debug] exe versions: ffmpeg 4.1, ffprobe 4.1
[debug] Proxy map: {}
[youtube] fBKScHaUo2I: Downloading webpage
[youtube] fBKScHaUo2I: Downloading player 1dda5629
[debug] [youtube] Decrypted nsig zROm0vk_ydYgrqth => bpxFOUJz11WpOQ
[debug] [youtube] Decrypted nsig 4sEOfLHP--BeSaCl => lEBErbvWHoGzEw
...
New in /mod/.cache/youtube-dl/youtube-nsig/
-rw------- 1 root root 5636 Fri 7 Jul 2023 17:40:44 1dda5629.json

Deleting and repeating:
Code: 
...
[youtube] fBKScHaUo2I: Downloading webpage
[debug] [youtube] Decrypted nsig f25UQ6FZ0gf92pT6 => zjMAI9TXpmVWTw
[debug] [youtube] Decrypted nsig _XY4FVhtLoWv5Ahz => 7syLntHcV-40sw
...
Nothing new appeared in /mod/.cache/youtube-dl/youtube-nsig/

Roughly 9 minutes to get to this point both times.
 
Deleting the downloaded content ?

Then maybe this player is sufficiently more complex that the descrambling takes that long. Overnight (?) queued download is the answer.

There is a possible work-around. The YT extraction tactics used in yt-dl and its fancier fork yt-dlp are described here. yt-dl could identify as an Android app and bypass the descrambling, but fewer formats are available. Some core changes would be necessary to be able to control the client selection as well. Overall, it's not at the top of the list.
 
You must log in or register to reply here.
Back
Top