dumrauf / youtube_to_audiobook Goto Github PK

The implementation of Issue #1 introduced a dependency on jq which needs to be documented and as such clearly visible to any user.

Hi, I have tried to follow your instructions on Linux Mint 20.3 and get the following output:

VirtualBox:~$ docker run -v "$(pwd)":/data -u $(id -u ${USER}):$(id -g ${USER}) dumrauf/yt2ab:v1.3.0 -u "https://youtu.be/gmmgWcbAmjo?list=PLZ-bKJtH3G7BYYscYohAFZAq65RwCf-K-"

[INFO tini (1)] Spawned child process 'yt2ab' with pid '7'
ERROR: gmmgWcbAmjo: YouTube said: Unable to extract video data
[INFO tini (1)] Main child exited normally (with status '0')

Any ideas?

The below example is taken from the "Introducing Playlist Support" blog post on How Hard Can It Be?!.

When closely inspecting the returned JSON documents for the "Genre: Science" YouTube playlist,

$ youtube-dl --dump-json --flat-playlist https://youtu.be/gmmgWcbAmjo?list=PLZ-bKJtH3G7BYYscYohAFZAq65RwCf-K-
{"url": "z5f2bpiAdLQ", "_type": "url", "ie_key": "Youtube", "id": "z5f2bpiAdLQ", "title": "The Fairyland of Science by Arabella B. BUCKLEY read by Various | Full Audio Book"}
{"url": "TGMGfCfpcqY", "_type": "url", "ie_key": "Youtube", "id": "TGMGfCfpcqY", "title": "The Extermination of the American Bison by William T. HORNADAY read by Various | Full Audio Book"}
{"url": "z5f2bpiAdLQ", "_type": "url", "ie_key": "Youtube", "id": "z5f2bpiAdLQ", "title": "The Fairyland of Science by Arabella B. BUCKLEY read by Various | Full Audio Book"}
...

the values of both the id and url keys seem to match for every individual JSON document; this can also be observed in numerous other playlists.

However, in order to remove the reliance on the assumption that the values of id and url keys match for every individual JSON document, we should move the extraction (and subsequent construction) of the YouTube URL from the id to the url key in the corresponding line of the main Bash script.

Thumbnails retrieved by youtube-dl seem to be named after the file provided by the server where the suffix seems to match the MIME type of the downloaded image; usually this is JPEG.

While not widespread, the thumbnails of some videos are being retrieved as WebP files which breaks the current logic based on JPEG.

The Bash script hence needs to be reliably extended (i.e., not introducing race conditions by relying on something like the 'most recent' file to pick up the correct thumbnail) to also work with WebP files.

At the moment, yt2ab can only process single video links. This can be a meticulous task when wanting to download an entire playlist. Right now, this requires manual look up as well as providing all the video links contained in the playlist. Boooring!

We should extend yt2ab to accept playlist links as input, especially since the underlying youtube-dl already provides most of the required functionality.

The introduction of playlist support in #1 has opened the floodgates to (sequentially) downloading multiple videos from YouTube. Understandably, YouTube doesn't take to its content being mass downloaded too well.

Rather than hitting YouTube with a large number of download requests in a short span of time, we should introduce a mitigating strategy which waits a random amount of time between successive downloads. This should somewhat simulate a "regular" YouTube user and hopefully delay being locked out to the point of it being no longer a problem.

Ideally, the wait time should be configurable.

While youtube2audiobook is only a very thin Bash script wapper around the great youtube-dl open source project, it still relies on numerous dependencies to be present before being able to run.

Not everyone might be willing or able to install the necessary dependencies. But, this being (late) 2020, there's a readily available solution for this: Containers.

We should really provide a Docker container that follows best practices, is properly tagged, and readily available on Docker Hub. Let's fully embrace the future!