YoutubeDL-Material: Can't issue any downloads at all right now
This has been the case in a previous version already, I think it started with 3.5, but I chalked it up to possibly a temporary issue. Looking back and actually reading the error code I might have a little bit of actual issue with the software itself. I think what’s happening is that youtubedl-material is passing a broken or bad argument? Idk
Here’s the log (freshly updated as you can see):
2020-04-13T09:00:57.265Z INFO: Beginning migration: 3.5->3.6+
2020-04-13T09:00:57.297Z INFO: 3.5->3.6+ migration complete!
2020-04-13T09:00:57.300Z INFO: YoutubeDL-Material v3.6 started on PORT 17442
2020-04-13T09:10:20.619Z ERROR: ERROR: u'' is not a valid URL. Set --default-search "ytsearch" (or run youtube-dl "ytsearch:" ) to search YouTube
(node:1) UnhandledPromiseRejectionWarning: Error: Command failed with exit code 1: /app/node_modules/youtube-dl/bin/youtube-dl -o video/%(uploader)s_[%(channel_id)s]/%(upload_date)s_-_%(title)s_[%(id)s].mp4 -f bestvideo[ext=mp4]+bestaudio[ext=m4a]/mp4 --write-info-json --print-json --download-archive video/merged.txt --write-sub --write-thumbnail --no-call-home --embed-thumbnail --sub-format srt/ass/best --sub-lang en,eng,de,ger,deu http://www.youtube.com/watch?v=J-2VSNPID2g
at makeError (/app/node_modules/execa/lib/error.js:56:11)
at handlePromise (/app/node_modules/execa/index.js:114:26)
at processTicksAndRejections (internal/process/task_queues.js:94:5)
(node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
This is when using regular YoutubeDL-Material on the WebUI in Docker. No extension, bookmarklet or API used.
Is the docker maybe missing a dependency?
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 21 (11 by maintainers)
Cool! Will test once my unRAID system is done testing parity. (I don’t have cache drives, so performance is wonky during parity checks when also running all the other tasks)
It’s always a pleasure 😃 And about creating an issue, sure! That would be helpful.
Btw, I just released 4.0, so check that out when you can! Haven’t noticed any bugs, but if you find any lmk and I’ll be on it
Haha it’s always the little things, no worries 😃 Glad we could get that working.
It would probably be relatively easy to implement, maybe an optional input when subscribing where you can set the custom output path. The only complication is that the path would need to be relative to the
{subscriptions folder}/{'channels' or 'playlists'}/{subscription name}folder. In the future, the videos won’t need to get stored in that folder (related to this issue) as the file information will instead get stored on the database in the same way non-subscription videos get stored now.Whenever I refactor subscription videos so they get to be stored in the database, I’ll make it so the subscription custom path will be used if available.
Good question! I’d say 3 days give or take a day.
I was thinking of doing a release-candidate but I think I’ll just use that time testing it a bit more. There’s the nightly Docker releases anyways which serve that purposes.
We’re almost there! I wanna make sure it’s as bug-free as possible. All that’s left is improvements to the args modifier. I want to make the args chips so it’s more visually appealing and some other usability improvements. After that I gotta translate, package the app, and write the release notes.
I’ll be changing strategies for the next few months to be more focused on bug fixes and usability and less focused on features. It’s mostly related to me starting an internship this summer so I’ll probably have slightly less time to invest. We’ll see. Anyways, that’s pretty much where I’m at on 4.0 and beyond.
Cool, that’s very thorough of you and good to hear!
Any ETA on v3.7 or v4.0? Just so I know when I can expect my latest stable build container to take over and to evaluate the CA again? (someone else already posted an unRAID CA, but I still intend to give this my own take on it and stand by my word of bridging unRAID forums to here and doing support and anything else that I can help out with.
No problem! About the apostraphes, forgot to address that: in my testing, I found that sometimes the apostraphes were being included as part of the arg. To prevent any errors by forcing their encapsulation, I just decided to use a double comma delimiter.
Hey! Just wanted to let you I’ve fixed the AtomicParsley bug (it will now be included in future Docker releases), and I’ve reworked the custom args to support filenames with spaces (related to #37).
Custom args (and global custom args) are now delimited by double commas (
,,) rather than a space (relevant commit). This prevents the latter part of a file with a space in its name from being considered a new arg. It’s double commas rather than a single comma so subtitle args, or any other args that use a comma will still work.That should fix all the issues here. Let me know if anything else comes up!
Yup, it would kill two birds with one stone (well, hopefully two).
I’ll play around with it a bit, but I’ll maybe have AtomicParsley be an optional dependency for embedding thumbnails if that actually fixes the issue. For Docker I can even update the existing 3.6/latest image so it will be included.
Anyways, thanks for the debugging help! I’ll keep this issue open until I get a fix out for both.
What’s interesting is the error message you got is for when a URL does not exist at all.
One other thing that caught my attention when investigating this error is this excerpt from a StackOverflow answer:
When I looked back at the youtube-dl commands that YoutubeDL-Material runs, there are no apostrophes in sight. This might be what is causing the parsing error. Just a guess, but I haven’t been able to reproduce your exact error so it’s hard to know for sure.
One way you could test this (if you have the package installed) is by running the youtube-dl command on your own, one with and one without apostraphes:
Without:
youtube-dl -o video/%(uploader)s_[%(channel_id)s]/%(upload_date)s_-_%(title)s_[%(id)s].mp4 -f bestvideo[ext=mp4]+bestaudio[ext=m4a]/mp4 --write-info-json --print-json --download-archive video/merged.txt --write-sub --write-thumbnail --no-call-home --embed-thumbnail --sub-format srt/ass/best --sub-lang en,eng,de,ger,deu http://www.youtube.com/watch?v=J-2VSNPID2gWith:
youtube-dl -o 'video/%(uploader)s_[%(channel_id)s]/%(upload_date)s_-_%(title)s_[%(id)s].mp4' -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/mp4' --write-info-json --print-json --download-archive video/merged.txt --write-sub --write-thumbnail --no-call-home --embed-thumbnail --sub-format 'srt/ass/best' --sub-lang 'en,eng,de,ger,deu' http://www.youtube.com/watch?v=J-2VSNPID2gIf the second one works, then we’re in business.
Might be that a package called AtomicParsley is missing which only gets invoked when the argument
--embed-thumbnailis passed, at least that’s what happens on my end. But the error I got was a bit different:ERROR: AtomicParsley was not found. Please install.Could you try the download without the --embed-thumbnail argument? Alternatively, just for testing, does downloading the video without additional args help? Maybe that will help us narrow down what might be causing this error.
What confuses me about the error you have is it seems like it’s a parsing error for the URL. But looking at the URL, it seems completely fine! Hm. Let me know if removing the custom args helps.