HOMO114514

VDO.Ninja 把手机摄像头投到电脑上的 OBS ，再开启 OBS 的虚拟摄像头

https://github.com/steveseguin/vdon_flutter/

@allenpu666
本地内容谁管你啊，不要在这里臆想。
现在绿联、飞牛、极空间、芝杜、Filmly 、Infuse 的海报墙不都用得好好的？那他们的数据为什么能合法获取呢？

我希望的是能有一家影视中心的套件，弄一个从 J/E/P 迁入的功能，配置好 Jellyfin 媒体库和本地硬盘的路径映射，自动匹配文件，并直接从他们那把管理好的所有数据拉过来，做到 0 人工介入的快速启动

再补充两个点

1. qbittorrent 是可以通过软件和 Web UI 更改文件名同时保持做种的
2. 转码确实没必要，转码很多时候是迫不得已，libass 作为一个纯 C 的字幕渲染引擎，在移动互联越来越流行的当下反而变得有点局促
a. Android 的原生 AndroidX.Media3 要求使用纯 KT 完成，导致纯 C 的 libass 一直不能合并入框架，并且也没有开发者愿意接手重构移植这个事情，所以 Android 上原生 exo player 渲染 ass 受限的问题已经将近 8 年没解决了
b. 浏览器内核太复杂了，虽然说现在的设备原生解码能力越来越强，但是浏览器内核才刚刚啃明白 hevc 10bit ，在 HDR 没有进入大众视野被强推之前它只是一个随便的 h264 播放器
具体可以参考 https://www.v2ex.com/t/1033031

单纯是 tmdb 不够强大，可它是免费的、社区维护的，你不能强求什么
更为严谨的 thetvdb ，对于电视剧系列提供了非常多的排序模式，同时在多语言、数据更新效率上全面碾压 tmdb ，也给 Jellyfin 和 Emby 出了官方插件，支持排序。

但是它的订阅是 11.99USD per year ，你愿意买单吗？

---

至于动画类，单纯是国内字幕组的命名规范和国际流媒体脱钩了，尤其是那些喜欢用方括号括集数的组，jf 这类解析引擎的默认行为都是忽略方括号。我自己实地测试，只要把正则
\[(\d+)\]
替换成
- $1
就能立马化腐朽为神奇。这串 regex 你可以直接用在 qbittorrent Web UI 的批量重命名和 power rename （本质上应该是同一个开源引擎）
目前只有极少数字幕组使用`[Group] Title - Episode.mkv`的命名格式，我推荐两个吧，压制组 Lolihouse 和北宇治 Kitauji

如果你不是跟我一样摸出这些规律的手动党，直接 auto bangumi v2 ，它会自动处理好所有东西

单说海报墙这个事情

还是在重复地造轮子，感觉每家做影音的都在造自己的海报墙，每家都不互通，反反复复地搞读取 SMB 匹配元数据，或者挂载阿里云盘百度云盘 API ，匹配元数据

包括 NAS 厂商、软件厂商

搞 NAS 的做不到三方 client 接入，如果自己的 client 做得是一坨狗屎，就根本没有可用性，比如绿联，ugos 和 ugos pro 全都是大便，骗一个是一个

软件厂商脱离了硬件盈利点之后搞封闭生态，并且没有提供迁入，从 JF/EMBY/PLEX 迁移过来的用户无论如何都要从头开始，每个人都影视库都有或多或少的错误内容，没有任何一个平台能提供 100%的准确度，所以重新入库就代表保守估计 10%的手动调整工作量，尤其是类似于里番/JAV 这种不接入第三方数据源根本无法实现刮削的内容

现在我看到比较好的是飞牛，本身影视墙是从 JF 魔改出来的，对 infuse 等第三方 client 直接提供了 jellyfin API 的接入，同时自己又能把数据做好，就算自己有覆盖不到的场景也可以化作等价 jellyfin server 继续服务

@mkdirmushroom
我调查说是有三方实现，比如 ATTO （ 200 刀）或者 Deamon （ 9 刀）
退一步来说，在本地放应用数据，然后用 NAS 的套件定期备份到 NAS 上也是可以的，看了一下目前我的 Jellyfin 数据 73GB ，256 的机器完全够用

@Jaie
@DandelionFlowers
存算分离，媒体挂 NFS ，应用数据挂 iSCSI

@fanyuanpei 没有公网，实际上 Tailscale 成功率是非常高的，双方网络环境恶劣对穿不了的话就遗憾淘汰

@Socrazy
1. 走 Tailscale 端对端网络
2. 不允许二级以上的社交圈加入网络，杜绝内鬼
3. 纯个人爱好慈善运作，不收一分钱
目前问题不大