PigeonPod vs Pinchflat：自托管 YouTube 下载、Podcast RSS、Plex 与 Jellyfin 怎么选？
PigeonPod vs Pinchflat：自托管 YouTube 下载、Podcast RSS、Plex 与 Jellyfin 怎么选？
PigeonPod 和 Pinchflat 都可以跟踪 YouTube source、下载媒体，并部署在自己的基础设施上。真正要比较的不是“谁能把视频下载到本地”，而是你的主工作流究竟是：在 Podcast App 里持续收听频道更新，还是维护一套本地媒体库。
PigeonPod self-hosted 把频道/播放列表订阅、音频或视频下载、私有 Podcast RSS 和应用内管理流程放在一起。Pinchflat 更偏向自托管 downloader 与媒体库管理，也能提供 Podcast RSS；但其官方文档将 RSS 标记为 beta，并要求管理员自行处理公网访问、认证和 feed endpoint。
只应添加受支持的公开 source，以及你有权访问的内容。两种方案都不能保证私有、下架、地区受限或其他受限媒体会变成可靠的本地库。
先说结论
如果你希望 Podcast RSS 是主工作流，同时也想保留可管理的本地音视频库，选 PigeonPod self-hosted。它适合在 Podcast App 跟踪内容更新，并按需让 Plex 或 Jellyfin 扫描下载的媒体目录。
如果本地 downloader 和媒体库才是第一优先级，选 Pinchflat。它更适合已经习惯配置、保护和维护 self-hosted service 的人；Podcast RSS 是额外的消费入口，而不是整个系统的中心。
如果你想要 PigeonPod 的收听工作流、但不想管理 host、storage、backup 和网络边界，则应考虑 PigeonPod Cloud。
两种工作流的核心区别
以 Podcast 为中心的媒体库
PigeonPod self-hosted
自托管 YouTube 订阅与下载流程，并将私有 Podcast RSS 作为核心交付方式。
- 适合
- 既需要 Podcast App 收听，也需要本地媒体库的人。
- 媒体结构
- 下载的音频与视频分开存放，可让外部媒体服务器扫描对应目录。
- 边界
- 存储结构由产品管理，并非任意 yt-dlp filename template 系统。
以本地媒体库为中心
Pinchflat
自托管下载和 source 管理工具，Podcast RSS 是可选的额外交付路径。
- 适合
- 主要目标是维护本地 YouTube 媒体收藏的人。
- Podcast App 访问
- 需要稳定公网 URL，并自行配置认证与 feed endpoint 暴露。
- 边界
- host、下载、存储、网络和 RSS 暴露均由你负责。
这是一篇工作流比较，不是永久不变的 feature checklist。在迁移大媒体库前，请以两边的最新文档为准。
下载与媒体归档
PigeonPod self-hosted 不只是轻量 RSS generator。它可以下载音频或视频，并将不同媒体 variant 分开存储。开源版本 v1.19.1 引入了独立 video storage directory，使管理员可以区分音频与视频库，再让 Plex、Jellyfin、Emby 或其他 scanner 扫描需要的目录。查看 PigeonPod v1.19.1 release notes
不过，独立目录不等于原生 Plex/Jellyfin integration。PigeonPod 并不承诺为所有外部 metadata agent 提供任意 output filename template；有关 yt-dlp 风格命名控制的需求已经标记为 not planned。查看相关 issue 因此，导入整个频道前，先用少量 episode 测试你的媒体服务器 scanner。
Pinchflat 在“本地收藏就是最终产品”时很有吸引力。关键不在于它能下载而 PigeonPod 不能，而在于你是要围绕订阅和 feed 组织收听流程，还是围绕下载文件组织自己的 media-library workflow。
Podcast RSS 的运维模型差异最大
在 PigeonPod 中，私有 Podcast feed 是核心交付路径：添加受支持的公开频道或播放列表，在 PigeonPod 内管理 source 和符合条件的 episode，然后在兼容的 Podcast App 里订阅。收听流程可参考 YouTube 转 Podcast 设置指南。
Pinchflat 同样能提供 Podcast RSS，但官方 guide 要求管理员让 instance 在家庭网络外可访问、选择认证方式，并显式开放 Podcast client 所需的 RSS、图片和媒体 endpoint。这是合理的 self-hosting 设计，但相关运维工作要由你承担。查看 Pinchflat Podcast RSS guide
如果你的 Podcast App 会从自己的 server 获取 feed，那么局域网地址通常不够。无论选择哪种方案，都应先在实际使用的客户端上测试刷新和播放，再迁移全部媒体库。
Plex 与 Jellyfin 是另一层交付方式
Plex 和 Jellyfin 是媒体服务器，不是私有 Podcast RSS 的替代品。它们适合在电视、浏览器或媒体客户端浏览、观看本地视频；Podcast App 更适合在手机、手表或车内维护 audio-first 的订阅队列。
PigeonPod self-hosted 可以把两种交付方式分开：Podcast RSS 用于收听队列，媒体服务器扫描视频目录用于 screen-first 浏览。Pinchflat 则自然以本地媒体库为主；当你还想在 Podcast App 消费某个 source 时，再补 RSS。
两边都不会免除基本 self-hosting 工作：storage capacity、backup、上游平台变化、远程访问安全和 upgrade 都需要你自己维护。
什么时候选 PigeonPod self-hosted？
- 你想把 YouTube channel 或 playlist 变成私有 Podcast subscription，而不是只有下载文件夹。
- 你希望在 Podcast App audio-first 收听，同时保留本地下载媒体。
- 你希望订阅、筛选、下载和私有 RSS 处在同一个产品流程中。
- 你希望音频和视频分目录，供 Plex 或 Jellyfin 扫描。
- 你能接受产品化的存储结构，而不依赖每个外部工具的自定义 filename。
什么时候选 Pinchflat？
- 你的第一目标是本地 download library 及其 media-server workflow。
- 你愿意配置稳定公网 URL、reverse proxy 或等效访问层、认证和 feed exposure。
- Podcast RSS 有用，但不是你最优先优化的产品边界。
- 你希望先评估 downloader-oriented workflow，再增加 Podcast delivery。
上线前做一次小范围验证
先用一个真实 channel 或 playlist 跑完整流程：
- 订阅一个受支持的公开 source。
- 下载几集音频和视频。
- 如果计划使用 Plex/Jellyfin，让它扫描目标本地目录。
- 在你离开家时实际使用的 Podcast App 里添加 RSS feed。
- 确认新内容同步、媒体播放、storage usage 与 cleanup 行为符合预期。
如果测试表明你同样重视 Podcast workflow 和本地媒体库，选择 PigeonPod self-hosted；如果本地库本身才是产品，选择 Pinchflat。若你想要 PigeonPod workflow 而不想承担运维，可直接使用 PigeonPod Cloud。