开发者生态
morning
下载您最喜爱的 YouTube 视频
2026-11-06
1 阅读
约6分钟阅读
surprisetalk
字号:
您绝对应该下载您最喜欢的 YouTube 视频 2026 年 10 月 13 日 信号增强劳拉的帖子,您绝对应该下载并存档对您重要的内容。企业互联网对艺术充满敌意,你所爱的东西并不属于你,除非你为自己主张。如果您已经在 YouTube 上呆了一段时间,只需查看您的“喜欢的视频”播放列表,看看有多少早期视频不再可用(您实际上必须在播放列表设置中启用该功能,这是普遍现象)。以基本方式执行此操作的工具非常容易掌握,并且通常具有良好的默认值。我还将谈谈我自己的设置,以及为什么它是奇怪的方式,但对于大多数设置来说这绝对是多余的。 yt-dlp 或其众多包装器之一将满足您的大部分需求,并且大容量存储驱动器或 NAS 上的文件夹足以确保您始终可以访问它们。但对我来说,我有一个特殊的需求 - 不幸的是,我已经对自己进行了编程,如果没有低音量的《Many a True Nerd Let's Play》,我几乎完全无法入睡。这带来了几个问题。我需要能够在电视上播放它。它必须集成到我现有的 NAS 基础设施中。我需要能够在数十个播放列表中组织数百个视频。这是一个比听起来更大的症结所在。添加新的或放置它们不能是手动工作。同样,数百个视频。我的 NAS 媒体库是围绕 Jellyfin 构建的,它有播放列表的概念,但它们实际上并不是作为一阶组织结构。您需要从一堆现有专辑中取出一些曲目,并将它们放在与实际 Library 分开的播放列表中。不,Jellyfin 对于电影、电视节目 > 季 > 剧集或艺术家 > 专辑 > 歌曲有非常严格的概念。电视节目是这里明显的类似物,通过一些非常疯狂的欺骗,我能够得到一个足以满足目前需求的设置。我的设置如下所示:在 Jellyfin 中,我有一个名为 YouTube 的电视节目模式库设置。我已经关闭了所有元数据抓取器等,并将其设置为更喜欢文件数据而不是文件名。这是唯一一个允许我在任何程度上正确维护播放列表结构的 yt-dlp 包装器,并且完全基于一系列 .yaml 文件。在它的自托管 docker-compose 形式中,它附带了一个 Web 应用程序 VSCode IDE,老实说,它非常方便 - 很好地弥合了技术与舒适度之间的差距。我有一个自定义流派和 MATN 播放列表列表,我希望它为其收集和设置元数据。您还可以在那里看到我有一些设置为“纪录片”的 Folding Ideas 视频 - 这更符合 ytdl-sub 期望的使用方式。事实是,99% 的 YouTube 用户和 99.9% 的观众并不特别需要将频道中的所有内容都构建为播放列表。大多数视频中一次性视频和系列视频的比例要高得多,这使得我的 MATN 结构完全毫无意义。因此,ytdl-sub 默认使用按年份组织的季节字段来标记视频,但它将它们存储在以播放列表命名的文件夹中。这导致 Jellyfin 将每个播放列表视频放在频道内的 2 个位置 - 年份系列和播放列表系列:我最近才意识到如何解决此问题,即将播放列表标题指定为我的 ytdl-sub 配置文件中的季号 - 看起来应该会损坏,但事实并非如此:我可以编写一个脚本来修复我所有现有系列的此问题,但问题是一旦 Jellyfin 导入了视频,我就无法获取它更新季号而不完全重新导入库,这是我对 TB 视频所做的事情并不真正感兴趣。哦,说到存储大小……Tdarr 是一项可以自动运行视频库并以您想要的任何方式重新编码的服务 - 通常是一些更小、更高效的格式或编解码器。我用它来将我的媒体服务器中的所有内容编码为 HEVC/H.265,因为存储是我的主要瓶颈 - 处理能力是权衡,而我对此是有把握的。老实说,我不会推荐 Tdarr,除非您非常乐意看到极其复杂且设计糟糕的 UI,并做出明智的决定来做到最少。我认识的每个使用过它的人都怀揣着实现出色的复杂工作流程的雄心壮志,并决定只使用默认的工作流程,因为它工作得很好。它倾向于破坏任何远程复杂的东西,我必须手动调整脚本,这样它就不会在任何时候有数据流时哭泣,但一旦它开始运行,它就会继续重新编码千兆字节又千兆字节。它似乎确实导致 Jellyfin 丢失缩略图图像,原因我还没有完全弄清楚,但它通常可以通过“刷新元数据”手动修复,或者在您选择的媒体管理软件中修复。它为我的 2TB 库节省了大约 700GB,尽管我可能可以避免一些
这篇文章对您有帮助吗?
订阅66必读
每日精选科技资讯,直达你的邮箱