[qtube] Webif front end for youtube-dl

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 said:
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 ...
Click to expand...
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.
 
/df said:
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.
Click to expand...
Feel free to submit a Git Pull request for any necessary changes to the qtube package
 
/df said:
I'm having trouble guessing where that is. Perhaps it's still private ?
Click to expand...
That's because it only existed in my imagination! :oops:

I thought I had added all of my packages to git but qtube obviously got missed, it is there now
 
/df said:
You appear to have included the critical change so I'll wait for the next release.
Click to expand...
Did I?
I don't remember that, it has been so long since I looked at the package,
although I want to do more maybe a less ambitious update would be worthwhile
 
bottletop said:
Anyone notice GitHub has taken down YouTube-dl due to DMCA?
Click to expand...
Yes, although a fair number of people are saying that it was not a DMCA request, despite how github have filed it. Will be interesting to watch developments.
 
everthewatcher said:
Oh dear. I use it with the GUI front end to watch longer videos on the TV via the HDR and a network share.
Click to expand...
That doesn't mean we can't use it (our code is already installed), just that GitHub have taken down the public sharing of the development process.
 
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.
 
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.
 
Pixel Eyes said:
Using youtube-dl (version 2020.09.20-3) and qtube (version 0.1.0-1) I get this message now:
ERROR: Unable to extract JS player URL ...
Click to expand...
For the moment the advice to contact https://yt-dl.org/bug is invalid. If you are prepared to reveal the problem URL, someone might be able to check the problem. If it's a YouTube video, you may have found this issue which is being worked on now by refugees from the vandalism of the main yt-dl repository.
 
You must log in or register to reply here.
Back
Top