主要是用mpv的自定义脚本，如同步观看记录和进度到trakt，加载同文件夹多个视频为播放列表，以及播放历史记录。
另外，不一定是读jellyfin的数据库，既然会读取文件夹里的poster.jpg 之类的，如果文件夹里面已经有 .nfo 的视频数据，也会读取吗？这样应该可以部分解决因没有内置ffmpeg而导致的视频元数据缺失问题。说部分解决是因为如果nfo文件，可能还是没法显示视频元数据。
mochi 本身就是纯本地桌面应用，海报墙、封面、元数据全都在你自己的硬盘上，不需要额外"保存"这一步。
拉取的海报都在本地，路径是 %APPDATA%\mochi\cache\，文件管理器地址栏粘贴就能打开。便携版在 exe 旁边的 cache 文件夹。
如果你指的是把海报墙导出一张图片方便分享，目前还没做，但确实是值得记一笔的方向。
.nfo 这个方向很好，技术上没什么障碍——纯 XML 解析，不需要 ffprobe。不过有一点需要先说清楚：.nfo 里主要是标题、简介、年份这些描述性信息，不是编码、码率之类的视频技术参数（除非你的 Jellyfin 开了 fileinfo 导出，但那个不是默认行为）。所以它解决的是「不想重复刮削」的问题，不是「没有 ffprobe 所以读不到时长」的问题。
和 mochi 自己拉取元数据的关系我这么想：扫描时读到 .nfo 就当初始数据用，标题简介先填上，不用立刻拉取。后面想更丰富的时候再从 Bangumi/TMDB 拉，在线数据覆盖 .nfo。这样从 Jellyfin 迁移过来的用户扫完就能看，不用等批量拉取跑完。
同文件夹播放列表这个，mochi 的做法不太一样——它不是播放器内部维护队列，而是扫描时就把同文件夹的视频归成一个系列，系列详情页里按集号排好。点一集开始播，播完自动跳到下一集。和你用 mpv 脚本加载同目录视频的效果一样，只是队列不在播放器里，而在系列页面上。你可以理解成：文件夹本身就是播放列表。
外部播放器暂时还是不支持。Trakt 同步倒是不需要 mpv 脚本，mochi 可以直接调 Trakt API——不过这个优先级会排在 .nfo 后面。
考虑到可能你不想更改自己的播放习惯，我会认真考虑在设置里加个外部播放器路径选项，但是优先级也不会高。
有 .nfo 就先用着，这样的话，我觉得挺好的。
是的，确实不用再调脚本了。
mpv 已经用了好几年了，主要是已经完全习惯了mpv的快捷键操作了，我不太清楚libmpv 和那个mpv播放器是不是有什么功能的区别。另外就是mpv 的一些自定义设置，主要是 HDR 之类的。
功能优先级什么的，按你自己想法来就行了，你也没有义务非得满足别人的需求。
大佬，能不能加个明亮模式啊，太黑了，看都看不清。
太黑了吗？一般应用背景都是在剧集横幅图填充状态的，你是指设置页吗？如果有截图能给我看看最好。
横排列表的展示方式太麻烦了，能否提供网格列表？
感谢反馈。这个问题我想了很久，最后的选择是在 v0.3.0 （今天晚点会同步到GitHub）加了搜索功能，而不是网格视图。原因不是网格不好做，而是 mochi 的核心体验是"海报即导航"——打开应用被一张大幅海报和流动的 fanart 接住，像站在展览厅里一幅一幅地看。网格视图会把这种沉浸感变成"文件管理器里挑文件"，技术上简单，体验上丢了 mochi 最特别的东西。
搜索的加入让定位单部剧的成本从"滑十几下滚轮"变成了"敲三个字母回车"。indicator dots 也改成了可点击跳转。这两个改动合在一起，我认为比网格视图更高效，同时不破坏首页的展览感。
如果以后有足够多的人觉得网格视图是刚需，我会重新评估——但大概率会做成一个和当前海报墙并存的第二视图，而不是替代品，因为一定有人更喜欢现在这种感觉（包括我自己）。
我一直在寻找一个能手动记录观看过的影视(封面，介绍，演员)，无需播放链接，有推荐吗
不能保存到视频文件吗？这样nas里的视频，挂载一下能看，emby能看，也不冲突
你在说本地化的豆瓣？Apollo（ios）、Moviebase（Android）、Movary可能是你想要的。
可以了，v0.3.5 刚加这个功能。mochi 现在能把元数据写回到视频文件夹（Kodi 标准的 tvshow.nfo / movie.nfo），海报背景图一起复制成 poster.jpg / fanart.jpg。NAS 挂载到 Emby 就能直接显示元数据，不会跟 Emby 冲突——mochi 默认不覆盖已有 NFO。
牛的，下周试试
要是能接上网盘就更好了
感谢使用。
请你帮我先确认几件事：
- 资源管理器地址栏直接粘
\\192.168.31.11\Shared能不能正常打开？里面能看到localMV和1.Movies吗？ 1.Movies里面是子文件夹（每部电影一个文件夹）还是一堆散装的.mkv平铺着？- 添加根目录时类型不要选"自动"，手动选"电影"再扫一次，看看结果变没变。
三个问题答案我大概就能判断是 SMB 那层的问题、还是 mochi 对你这个目录结构的兼容问题。
后续 bug 跟踪和修复进度可以直接走 GitHub issue，这样不容易跟丢：GitHub - NandySun/mochi
网盘这块我考虑过一段时间，目前没有接入计划。主要是 mochi 定位是本地数字收藏柜——海报墙、续播记忆、外挂字幕都是基于"文件在我硬盘上"这个前提设计的。网盘要走 OAuth + HTTP 流式拉取，路径跟现在的播放器架构完全对不上，强行做出来体验会很碎。
不过有个零成本的折中：用 rclone 把网盘挂载成本地盘，Windows 上是 rclone mount remote:path Z:（需要 winfsp）。挂好之后在 mochi 里加 Z:\Movies 路径就行，扫描能跑。播放走流式，体感上不如本地 SSD，但能看。
如果你主要是想"在 mochi 里看到网盘里的电影"，rclone 够用。如果是想"点开秒播不卡"，那得等网盘自己有高速通道，不是 mochi 能解决的。
网盘挂载就行，就是是不是后面可以考虑优化一下挂载盘扫描的老大难，请求过多导致网盘账号临时ban的问题 115 就很严重
话说，可以考虑把元数据和文件分开存储吗？
文件的话，仍然可以放在百度、115 网盘里面去。用 rclone mount 挂载。
元数据则是放在本地，或者放在“云软盘”里面。云软盘可以能方便地在本地挂载，支持分享给少数几个好友，也可以把本地的元数据定时打包发布到网络去。
不过比较麻烦的是，元数据怎么样对应对百度、夸克、115 里面的资源。最好是资源的文件名带个 hash 值。
元数据和文件分开存储，技术上应该没问题，但我目前不打算做同步层。对我来说更务实的方向是在现有单机框架上做分层：文件不挪就不算 hash，挪了走相对路径重定位，还不够才惰性算内容指纹。跨平台匹配从实际角度看只在这个框架的最后一步才需要上场。