ytdl_hook: broadcast ytdl_path and json #10410
Conversation
Scripts that wanted to use yt-dlp/youtube-dl had to either search for it themselves or provide an option for users to set a valid path for it. ytdl_hook already does the work of finding a valid ytdl_path, so share that path with others via a script message. Scripts that wanted to use the json from yt-dlp/youtube-dl for the currently playing file had to call yt-dlp/youtube-dl themselves. ytdl_hook already calls yt-dlp/youtube-dl to get that json, so share that json with the corresponding url via a script message.
christoph-heinrich
force-pushed
the
ytdl_hook_broadcast_json
branch
from
d0ff6e2
to
2dcd1cd
Compare
christoph-heinrich
changed the title
|
From the discussion on IRC it became clear that this is never going to land and quality-menu is basically just a work around for deficiencies in mpv and I should be working on those instead. |
|
Basically the info (all available ytdl tracks info) is already exposed as track metadata when using However, OP doesn't use all-formats=yes because there's a bug where it doesn't work with So to work around this bug and issue, and to get the available info without enabling all-formats=yes but with --vd-queue, they wanted to broadcast the JSON so that a script could capture the track metadata for all tracks even without all-formats=yes. Other than being an ugly hack to work around some others issues and local limits, it has another big problem where this JSON is basically a dump of raw data directly from ytdl. Such raw data cannot be relied upon by scripts, as it can change at any time. For instance if tomorrow ytdl-hook invokes ytdl twice, or if tomorrow it's invoked in a way where the JSON doesn't have the other tracks info (because ytdl-hook doesn't actually need the info for other tracks when not using all-formats=yes), etc. If there's info which ytdl-hook has privately but which could be useful to other clients/scripts, then we could export this in a well-defined way, which scripts can rely on (and probably as a shared script property rather than broadcast). But this PR serves nothing except solving a very unique and specific limitation, and is not useful to any script other than to work around the described limit. |
Share the found path to yt-dlp/youtube-dl and the acquired json for videos with other scripts.
I've been using this together with a modified quality-menu for about a week now without any problems and was curious what you think about this.
There are currently no script messages being sent out to user scripts (afaik), but this seems like the easiest way of sharing that information with others.
The documentation is based on the one for events.