I noticed the symlink has been deprecated in favor of this small wrapper : #!/usr/bin/env sh exec yt-dlp --compat-options youtube-dl "${@} The issue is now when I launch my youtube-dl script to fetch new videos, it causes unwanted output the script has finished scanning for new videos. (using the archive option) time=" 300.215" type="debug" -> core: Starting auto-download event, remaining 715 minutes out of 720 total minutes to next global feed update. time=" 360.207" type="debug" -> core: Starting auto-download event, remaining 714 minutes out of 720 total minutes to next global feed update. time=" 420.209" type="debug" -> core: Starting auto-download event, remaining 713 minutes out of 720 total minutes to next global feed update. time=" 473.319" type="debug" -> core: Cleaning up resources and saving application state. time=" 473.319" type="debug" -> core: Close lock was obtained safely. time=" 473.324" type="debug" -> core: Stopping StandardServiceRoot instance. time=" 473.324" type="debug" -> feed-downloader: Destroying FeedDownloader instance. time=" 473.399" type="debug" -> gui: Destroying FormMain instance. time=" 473.400" type="debug" -> gui: Destroying TabWidget instance. time=" 473.400" type="debug" -> gui: Destroying FeedMessageViewer instance. time=" 473.400" type="debug" -> gui: Destroying BaseToolBar instance. time=" 473.401" type="debug" -> gui: Destroying MessagesView instance. time=" 473.401" type="debug" -> gui: Destroying BaseToolBar instance. time=" 473.402" type="debug" -> gui: Destroying FeedsView instance. time=" 473.405" type="debug" -> gui: Destroying TabBar instance. time=" 473.406" type="debug" -> gui: Destroying StatusBar instance. time=" 473.407" type="debug" -> gui: Destroying SystemTrayIcon instance. time=" 473.415" type="debug" -> core: Destroying Application instance. time=" 473.415" type="debug" -> core: Destroying Mutex instance. time=" 473.433" type="debug" -> gui: Destroying IconFactory instance. time=" 473.433" type="debug" -> core: Destroying FeedReader instance. time=" 473.433" type="debug" -> feed-model: Destroying FeedsModel instance. time=" 473.433" type="debug" -> feed-model: Destroying FeedsProxyModel instance time=" 473.433" type="debug" -> message-model: Destroying MessagesModel instance. time=" 473.434" type="debug" -> message-model: Destroying MessagesProxyModel instance. This wasn't happening with the symlink method. (and so, without the --compat option which I don't need and that is being somehow forced) For reference, my script : DIR="$HOME/yt" DL_DIR="/mnt/data/youtube" youtube-dl --ignore-config \ --ignore-errors \ --format best \ --prefer-free-formats \ --add-metadata \ --downloader aria2c \ --downloader-args "aria2c:-x 16 -s 16 -k 1M" \ --download-archive "$DIR"/youtube-dl-archive.txt \ -a "$DIR"/youtube-dl-channels.txt \ -o "$DL_DIR/%(uploader)s/%(upload_date)s - %(title)s.%(ext)s" Reproducible: Always
Also, the "debug" messages caused by --compat option prevent the script from exiting correctly although it finished scanning and downloading every channel in my archive file.
What do you mean forced? Just don't use the compatibility wrapper? The wrapper is primarily intended for compatibility with applications that haven't migrated to yt-dlp yet, there's many differences between the two that will break these (documented in the yt-dlp's README). Option may have issues (reporting upstream may make more sense) but removing it would cause even more. Ultimately the idea would be to no longer provide "youtube-dl" at all and for everything to use "yt-dlp" directly, albeit that'll probably be a few years for everything to migrate.
On that note, I guess I could add a brief 1-time message to the ebuild before this is made stable to inform about this wrapper.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=05e34ac3f3f95c4affc0654d04cc1f790d6dc454 commit 05e34ac3f3f95c4affc0654d04cc1f790d6dc454 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2021-10-30 22:59:27 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2021-10-30 23:10:21 +0000 net-misc/yt-dlp: add note about youtube-dl wrapper Mostly to discourage use when not explicitely needed. It may be less tested and, while no plans are known for this, upstream deciding to remove compat options at some point wouldn't be a surprise. Will either way become obsolete when everything is calling yt-dlp directly. Bug: https://bugs.gentoo.org/820842 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> net-misc/yt-dlp/yt-dlp-2021.10.22-r2.ebuild | 9 +++++++++ 1 file changed, 9 insertions(+)
(In reply to Ionen Wolkens from comment #2) > Option may have issues (reporting upstream may make more sense) but removing > it would cause even more. For one example, yt-dlp has a different default output filename that may surprise applications. compat-options even has messages to match old youtube-dl, e.g. > $ yt-dlp -F ... > <snip> > [info] Available formats for C0DPdy98e4c: > ID EXT RESOLUTION FPS | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO > --- ---- ---------- --- - ---------- ----- ----- - ------------- ----- --------- ---- ------- ----------------- > 139 m4a audio only | 106.32KiB 49k https | mp4a.40.5 49k 22050Hz low, m4a_dash > $ yt-dlp --compat-options youtube-dl -F ... > <snip> > [info] Available formats for C0DPdy98e4c: > format code extension resolution note > 249 webm audio only low 21k , webm_dash container, opus @ 21k (48000Hz), 47.04KiB While this is not replicated with the symlink, so I wouldn't want to revert. Please report issues upstream if the option isn't working as expected, and use yt-dlp directly if you don't want the option passed.
(In reply to Ionen Wolkens from comment #2) > What do you mean forced? Just don't use the compatibility wrapper? > What do you mean forced? Just don't use the compatibility wrapper? Indeed, sorry, I was a bit confused... Indeed, I can do that and call directly "yt-dlp" in my scripts.. instead of relying on old "youtube-dl". On a side note, this kind of debug output when --compat is used although --debug is not called is a bit strange but indeed that's something to report on yt-dlp, not here. Thanks for your patience and the quick note.
