• 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.

[qtube] Webif front end for youtube-dl

I dunno. I haven't yet tried it. I just copied it from someone's answer to solve a problem I was having.
Anyway, the point is that what you type in the box should be passed verbatim and not modified en route.
 
prpr said:
Anyway, the point is that what you type in the box should be passed verbatim and not modified en route.
Click to expand...
That is the goal!
But every time data gets passed across an inteface rules about escaping special character and quoting/bracketing strngs get applied.
The options need to arrive as if they had been typed directly in a command window.
Hopefully that is the case without the user needing to apply multiple layers of escaping
 
prpr said:
I typed this into the qtube "Process options" box:
-f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio' --merge-output-format mp4
and what it executed was this, according to the auto processing log:
qtube -f {'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio'} --merge-output-format mp4

This obviously failed, with an unavailable format error. I presume this is the result of some Jim stupidity somewhere.
Click to expand...
I suppose the [] in the format mean that Jim wants to escape the format string but I can't see any way of unescaping it in Jim. I thought that I managed to force the {} out of the command line of the /mod/bin/youtube shell script at the last possible moment by hacking the dequeue routine, but that was a mirage.
 
Last edited:
I suspected there was more work to be done on parameter passing :(

I still find JIM a strange language and need time to get my head around things like that lmap command
I'm happier using REXX as a scripting language :eek:
 
MymsMan said:
I still find JIM a strange language
Click to expand...
Yes, me too, which is probably why I dislike it.
I'm happier using REXX as a scripting language
Click to expand...
That had its own weirdness too.
The trouble with all these scripting languages seems to be that you are never quite sure what it's going to do. This usually means you end up writing stuff which has loads of unintended consequences AKA bugs.
 
prpr said:
I typed this into the qtube "Process options" box:
-f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio' --merge-output-format mp4
and what it executed was this, according to the auto processing log:
qtube -f {'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio'} --merge-output-format mp4

This obviously failed, with an unavailable format error. I presume this is the result of some Jim stupidity somewhere.
Click to expand...
The problem is the use of single quotes, it works with either double quotes" or braces {}
-f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio" --merge-output-format mp4 or
-f {bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio} --merge-output-format mp4
This works without the need for @/df's changes

Single quotes are not alternatives for double quotes for strings in Jim/Tcl so are retained as part of the string when youtube is invoked from the webif while when invoked from the command line they are stripped from the arguments passed into youtube by the shell

So this falls into the 'Jim stupidity' category but since there is a simple workaround I am not going to attempt to fix it now.
 
MymsMan said:
...I still find JIM a strange language and need time to get my head around things like that lmap command
...
Click to expand...
It helps to have some Lisp. I recommend "Structure and Interpretation of Computer Programs", which you can find online and was the basis of an introductory course at MIT (no GOSUB 100 stuff for those students). In different ways, Jim aka TCL and JavaScript rework concepts from Lisp.

Having said that, the Jim escaping wasn't the problem, but an artefact of logging in the dequeue routine, as below:
MymsMan said:
The problem is the use of single quotes, it works with either double quotes" or braces {}
-f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio" --merge-output-format mp4 or
-f {bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio} --merge-output-format mp4
This works without the need for @/df's changes
...
Click to expand...
And in fact those changes didn't have a useful effect because the problem is actually that the single-quoted parameter value is being passed to yt-dl in "$@" which quotes it again, so its command line has "'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio'"; the shell strips the double quotes and yt-dl gets the parameter still with quotes, as can be seen by adding the -v option:
Code: 
...
[debug] Command-line args: [u'--config-location', u'/mod/etc/youtube-dl.conf', u'--newline', u'-v', u'-f', u"'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo+bestaudio'", u'--merge-output-format', u'mp4', u'https://www.bbc.co.uk/iplayer/episode/b08b7blz/absolutely-fabulous-the-movie']
...
In this example, there's actually no need for quoting at all, though there might be if any parameter value contained white space or a ".

In the POSIX shell $@ is a near synonym for $*; $* expands to the positional parameters from $1 up; when quoted "$*" expands to the quoted "$1 ... $n", whereas "$@" expands to the individually quoted positional parameters from "$1" up, or nothing at all if there are no positional parameters.

So
  • if /mod/bin/youtube, as now, uses "$@", the options field needs to use Jim quoting ({}, "", \) if an option value contains white space;
  • if it's changed to use just $@, the options field can use shell quoting instead (but some testing would be good to check \ and ", which are escapes in both Jim and POSIX shell).
 
One of my HDR-FOX T2s has youview.dl version 2020.09.20 installed but there is no link to qtube on the webif front page or the header banner. Entering http://<hdr's_ip_address>/plugin/qtube/? directly into the firefox or edge browsers comes up with a webif message "Sorry, this page is not available".

It was OK up to 3 weeks before I ran RMA and reloaded almost everything from scratch. (After reload I found some settings had remained with other packages I.e. sweeper flags on subfolders, sweeper rules on My Video folder, MultiMode settings and Tunefix force LCN settings.)

I have since cleared my cash on both browsers, uninstalled youtube.dl and rebooted, and reinstalled youtube.dl again and rebooted, but the frontend for qtube front end remains inaccessible to my efforts to display it. I haven't noticed anything else amiss with any thing else, although my crash rate has severely reduced and it has been crash free for 10 days.

Any ideas for getting the front end to display?

Web interface version: 1.4.8-8
Custom firmware version: 3.13 (build 4028)
Humax Version: 1.02.20 (kernel HDR_CFW_3.13)
 
Luke said:
Any ideas for getting the front end to display?
Click to expand...
qtube is a separate package to youtube-dl, and has to be re-installed separately after an RMA. Had you installed qtube instead of youtube-dl, youtube-dl would have been installed automatically as a dependency. Note you will need to show advanced packages.
 
Hi All,

Just been trying to refer to a text file to download a series of urls. Simple text file, each new line is a URL. I have managed to get it to work but only using the Download now option with nothing in the URL and this syntax:

Code: 
-a /media/My\ Video/temp/DH-test.txt

(the \ is to escape the proceeding space)

But when I try the download via the background option it says file does not exist

1602619343085.png

I'm wondering if it's due to the space in 'My VIdeo' and the background option isn't recognising the backslash '\' as an escape character? I've tried various options putting the path in quotes and other things but still the same issue.

Is it a syntax issue or a problem with the program do you think?

Thanks

Rodp
 
did also try a path without a space but no luck either however this time the { } brackets were removed

Code: 
-a {/mnt/hd2/mod/test/DH-test.txt}

1602621338730.png
 
The Queue process was initially designed for use with recordings which had to pre-exist. it was extended to support URLs for qtube but we never anticipated using it with a null URL.

I can't recall what trigger it uses to recognize URL vs file

You could try a dummy url at the end or possibly put -a in opts and the file name in the url field put I think that will fail because it isn't a .ts file
 
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, in particular with this line of /mod/webif/plugin/qtube/queue.hook.
Code: 
#was
#    set cmd "youtube --newline {*}$opts $url"
#new
    set cmd {youtube --newline}       
    lappend cmd {*}$opts $url
Also in /mod/webif/plugin/qtube/queue.jim
Code: 
--- queue.jim.org
+++ queue.jim
@@ -15,7 +15,8 @@
 
 set url [cgi_get url -]
 set queue_time [cgi_get queue_time 0]
-set opts [cgi_get opts '']
+set opts [cgi_get opts {}]
 #puts "queuing $url $opts"
-exec {*}qtube -start $queue_time {*}$opts $url >@stdout
+lappend opts $url
+exec qtube -start $queue_time {*}$opts >@stdout
I don't say that this is the minimal set of changes needed but I'm now able to use -a as the last parameter in the Options field and name a local batch file in the URL field, like so:
Code: 
14/10/2020 15:31:44 - Completed queued download of /tmp/te st.txt Options -F -a
Not a problem here, but there is a bug in the yt-dl manual and online help which lists URL as a mandatory parameter, which isn't true if -a is used.
 
Last edited:
This is a bit nasty and really should be trapped:
Code: 
humax ~ # qtube 
18/10/2020 11:34:22 QT(4485)- Starting URL:  options: 
18/10/2020 11:34:22 QT(4485)- Queued id: 12831 URL:  options:
 
You must log in or register to reply here.
Back
Top