[qtube] Webif front end for youtube-dl

[/df]

Good for one YT download just now, thx.

 

[MontysEvilTwin]

Hope everyone is having a relaxing Christmas. I used qtube to download a boxset. It downloaded episode 1 first (as expected) and then downloaded ep. 6 then ep. 5 etc. Why would it not download them in the order submitted (1-6)? I understand why, it sees a list of episodes 2 to 6 and downloads them from the highest number to the lowest. This is suboptimal behaviour since the timestamps mean that the episodes are displayed onscreen out of order. It is OK as I did not want to watch these all straightaway, otherwise after watching the first episode I would have had to wait for the second to download though I could have watched 4, 5 or 6.

 

[peterworks]

The BBC are having problems:
"*** January 2019 *** We're aware that some people are seeing a "Download Failed" message when trying to download a programme via BBC iPlayer Downloads on computers."
This is affecting youtube-dl too.
On trying to use QTube overnight to download a BBC program it, as expected, failed. However, QTube left some 'temporary' files behind when it stopped.



Would it be possible to ensure that, either on completion or after a failure, all temporary files are removed?

Edit: It worked fine using the portal and saving the streamed file.

 

[MymsMan]

Would it be possible to ensure that, either on completion or after a failure, all temporary files are removed?

The simple answer is No

There are a number of reasons for this:

1. Youtube-dl resumes incomplete downloads - deleting files would force a complete restart from scratch
2. If the failure is caused by a humax crash or power off no clean up is possible
3. qtube is a very dumb front end to youtube-dl, it has no idea whatsoever of which files will be created by a download so wouldn't know what to clean up

 

[peterworks]

The simple answer is No

Thanks...

 

[Black Hole]

(Risen to my attention again because I want to download something and needed to remind myself how...)

It would be nice to have a selection of options available as tick boxes (eg restricting image resolution and container type).

I'll think about it but want to keep it simple

How about a Christmas present? I still think qtube as a front-end for youtube-dl could provide more user aids. What I'm thinking is some preset tick boxes which insert appropriate strings into the "Process options" field... otherwise I have to look them up each time. Also, I have put a unit in the hands of a user who could use qtube (with guidance) but would be put off by the intricacies of youtube-dl.

EG:

"Restrict resolution to SD quality" inserts -f "height=540" (or something).

Is the "run download now" button action protected in an abduco session?

No, because it needs to capture the output to display

Doesn't the tee command resolve that?

 

[MymsMan]

How about a Christmas present? I still think qtube as a front-end for youtube-dl could provide more user aids. What I'm thinking is some preset tick boxes which insert appropriate strings into the "Process options" field... otherwise I have to look them up each time.

I am not promising anything but my free time should be greater in the New Year now that a long running legal case I was involved in has been resolved.
There are also a number of DetectAds updates to be made (including @Matthew 's) and I want to learn how to use git so that is easier to track changes and they can be stored on github

The Magnificent Mad Madam Mym may have other ideas of how I should be spending my time!

A list of possible preset names with associated process options would save me having to guess what might be useful.

 

[Black Hole]

I am not promising anything but my free time should be greater in the New Year now that a long running legal case I was involved in has been resolved.

Ouch!

A list of possible preset names with associated process options would save me having to guess what might be useful.

Everybody submit their favourites.

-F could be catered for by replacing the "Run download now" button with a "Download manifest" button.

 

[Black Hole]

I've hit a problem I suspect I had trouble with before and put me off qtube.

I downloaded the manifest, then put -f "height=540" into the options box, and here are the relevant lines from the log:

09:26:04 - stream-uk-iptv_streaming_concrete_combined_hd_mf_limelight_uk_hls_https-3117-0               mp4        960x540    3117k , avc1.64001F@2812k, 50.0fps, mp4a.40.2@128
...
21/11/2019 09:28:01 - Starting queued download URL https://www.bbc.co.uk/iplayer/episode/m00095td/the-name-of-the-rose-series-1-episode-1 Options -f height=540 QID 11461
...
21/11/2019 09:29:08 - Caught error: ERROR: requested format not available

Note the Options says -f height=540 not -f "height=540". Does that matter? Is the parsing (or parameter passing) stripping the double-quotes inappropriately?

I have the download in progress now, by modifying the config file to read -f "best[height<=?540]". What I haven't done is try that string in the Options box.

 

[Black Hole]

Can anybody tell me why putting --audio-format mp3 in the Options box doesn't work? From my reading of the youtube-dl documentation, that should download from the URL (in this case an iPlayer radio programme, which downloads as .m4a) and then run a conversion through ffmpeg into MP3.

Answer (distilled from post below): the Options box entry needs to be -x --audio-format mp3.

 

[MymsMan]

Can anybody tell me why putting --audio-format mp3 in the Options box doesn't work? From my reading of the youtube-dl documentation, that should download from the URL (in this case an iPlayer radio programme, which downloads as .m4a) and then run a conversion through ffmpeg into MP3.

No, and it is unlikely to be related to the front end so probably really belongs in the [youtube-dl] thread

The first things to check would be whether it works from a PC command line and then a Humax command line

 

[Black Hole]

You're right, I get the same result on the Humax command line.

If I can get this to work (as a qtube option), I won't be so impatient for a means to push commands onto the queue.

 

[/df]

Can anybody tell me why putting --audio-format mp3 in the Options box doesn't work? From my reading of the youtube-dl documentation, that should download from the URL (in this case an iPlayer radio programme, which downloads as .m4a) and then run a conversion through ffmpeg into MP3.

The same documentation says that you also need to use the -x (== --extract-audio) option to enable --audio-format -- but surely you read to the end of the paragraph. It also suggests that this applies to video files.

If that doesn't help, you could try --exec 'ffmpeg -i {} {}.mp3'. This will (if it works) leave an output file with extension .m4a.mp3, but with a script /mod/bin/tomp3 like this (and chmod a+x /mod/bin/tomp3)

#!/bin/sh
ffmpeg -i "$1" "${1%.*}.mp3"

you could try --exec 'tomp3 {}'. Obviously you could also include codec options to control the output bit-rate, etc, in either of these formulations.

 

[Black Hole]

...and exactly the same on a Windows command line.

 

[Black Hole]

The same documentation says that you also need to use the -x (== --extract-audio) option to enable --audio-format -- but surely you read to the end of the paragraph.

Oops! No, I didn't notice that: "No effect without -x" - I'll give it a try (yes, I know how to convert as a separate operation).

 

[/df]

Oops! No, I didn't notice that: "No effect without -x" - I'll give it a try (yes, I know how to convert as a separate operation).

The --exec thing is an alternative to put in the qtube options in case yt-dl is actually serious about only extracting audio from video files.

 

[Black Hole]

It seems to be working, but slow (of course) so I await results. I am a little bemused that the conversion still seems to be running (and output file growing) even though I deleted the .m4a file (via SMB) - I was trying to terminate the command line session to try the qtube options line.

 

[Black Hole]

Yeah, working as a qtube option too. Have bolted into my summary guide.

 

[/df]

It seems to be working, but slow (of course) so I await results. I am a little bemused that the conversion still seems to be running (and output file growing) even though I deleted the .m4a file (via SMB) - I was trying to terminate the command line session to try the qtube options line.

You deleted the directory entry but the file would not have been deleted while it was still held open by ffmpeg.

 

[prpr]

I am a little bemused that the conversion still seems to be running (and output file growing) even though I deleted the .m4a file (via SMB)

Linux doesn't actually delete the file until the last user of it closes the file. It disappears from the directory listing when you issue the delete instruction though, which is probably what confuses you.
You should terminate processes properly using kill or pkill, rather than trying to do it by deleting the file. As you have now discovered, the latter does not work.