[qtube] Webif front end for youtube-dl

/df

Active Member
Here's a "feature".

If the site offers a download that is a single media file using https, youtube-dl will try to download the file itself. If the site requires "modern" security protocols for https, this will fail: unable to download video data: <urlopen error [Errno 1] _ssl.c:499: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version.

For such a site (eg DailyMotion), use the option --external-downloader wget, or, to avoid having to do that at the possible cost of making some downloads use more resources than necessary, --external-downloader ffmpeg.

The latest wget and ffmpeg are up to speed with TLS. Another option, if whoever built the python package still has the build environment, would be to rebuild python linked to the latest libssl.
 

/df

Active Member
Using a dummy URL does cause an unwanted error message in the log.

There may be an issue with the way commands are queued, as well as how qtube uses the queue.

[proposed change to queue.class]
...
But that's no help unless this line of /mod/webif/plugin/qtube/queue.hook is also changed.
....
Also in /mod/webif/plugin/qtube/queue.jim
....
I don't say that this is the minimal set of changes needed ...
The qtube changes that I proposed are necessary to support a "URL" with spaces, as for instance the name, containing spaces, of a file containing URLs with Options ending in "-a", and this code also supports a URL /dev/null and Options ending in "-a" followed by the double-quoted name, containing spaces, of a file containing URLs.

Apparently queue.class works fine without changes if the args are passed correctly.
 
OP
MymsMan

MymsMan

Ad detector
The qtube changes that I proposed are necessary to support a "URL" with spaces, as for instance the name, containing spaces, of a file containing URLs with Options ending in "-a", and this code also supports a URL /dev/null and Options ending in "-a" followed by the double-quoted name, containing spaces, of a file containing URLs.

Apparently queue.class works fine without changes if the args are passed correctly.
Feel free to submit a Git Pull request for any necessary changes to the qtube package
 

/df

Active Member
Although the notice listed 18 GitHub projects, a number of forks are unaffected and the total number of available forks is increasing at about 1 a minute. This of course doesn't include many projects that separately pushed yt-dl code to GitHub without using the Fork function, nor the one whose description says it is a "tool that does not download videos from YouTube" (and which does not include some test URLs at issue), nor the many other web-based repositories where users have far-sightedly uploaded versions of the program, and obviously not any of the thousands of local Git repositories checked out from the suspended project(s).

So it's a case of good luck with that.
 

/df

Active Member
While the package is being delivered from all the main Linux distributions, not to mention to any Windows system enhanced with Chocolatey, and any Mac with Home Brew, I don't think we need to be concerned.

Option of the day

Suppose your selected download link turns out be going to deliver you a .mkv file. In "Process options", use --recode-video mp4. This will run ffmpeg to convert the download's media container to mp4 after the download has finished. Don't try playing the resulting mp4 until it's fully converted as the UI may lock up (guess how I know).

Elsewhere, I posted instructions for watching YouTube free-to-air showings of certain football matches by converting the live stream to .m2ts, but that isn't one of the container types known to the --recode-video option.
 
Top