用RomM在NAS上搭建私人游戏库，让老游戏封面墙随点随玩

上个月整理书房翻出一块吃灰多年的移动硬盘。里面装着我从 GBA、NDS、PS1 一路攒下来的老游戏镜像总量好几百 GB命名乱七八糟目录层层嵌套有些平台连文件夹都分了三个版本。我想找一两个打开重温光是“找到哪个文件对应哪个游戏”就花了大半夜。后来我把这些文件全部搬家到 NAS 上用 RomM 建了一套类似 Steam 游戏库的索引。现在想在客厅玩老游戏只要在浏览器里打开 NAS 的 IP输入密码就能看到整整齐齐的封面墙点进去有说明、有截图甚至能用搜索和收藏夹快速定位想要的版本。今天这篇就把完整思路写出来老游戏文件如何放、RomM 怎么部署、封面和资料怎么刮削以及我在群晖、飞牛这类 NAS 上实操踩过的坑。1. 老游戏库从“能存”到“能逛”先想清楚整体架构1.1 文件堆叠式管理为什么不可持续多数人收藏老游戏的流程都一样下载或备份到某个目录偶尔解压跑一下玩完就继续放着。刚开始只有几十个文件时还好一旦过了上千个文件问题就全冒出来了。文件本身没有可视化封面你根本想不起一个叫“Mario-0305(USA).z64”的文件到底是什么版本、有多大、是否通关过。跨平台更麻烦GBA、SFC、N64、PlayStation 的资源混在一起光“找文件”就足够劝退。而且这些老游戏大多没有元数据打开文件夹看到的全是英文字母缩写不双击运行根本认不出内容。这就是典型的“数据能存但不可用”状态。存的目的是为了以后能快速找、快速预览、快速玩如果每次都要翻文件名去猜这套存档就没有意义。1.2 RomM 到底解决了什么问题我第一次看到 RomM 的时候第一反应是这不就是给老游戏做的“群晖相册”吗它从你指定的目录里读取 ROM 文件自动识别所属平台去 IGDB 资料库拉取封面、简介、发售年份然后生成一个随时可以浏览的网页前端。你可以把 RomM 理解为“媒体服务器界的 Jellyfin但服务对象是游戏 ROM”。它不管模拟器、不管存档、不管手柄映射只负责两件事把一堆散乱的文件变成有封面、有介绍的数据库把数据库以类似 Steam 的横向封面墙形式呈现出来。这个定位非常聪明。模拟器这种东西更新换代太快今天用 RetroArch明天可能换 standalone core今天在电脑上玩明天可能在手机上玩。但你的游戏文件应该是相对稳定、不依赖某个模拟器存在的。RomM 把“游戏资产库”从“模拟器工具链”里剥离开正好贴合 NAS 的核心价值数据一次存放多端随时使用。1.3 为什么最终没选 ES-DE、Batocera 或 RetroArch也许你会好奇市面上的游戏前端明明不少为什么偏偏用 RomM我并不是说其他方案不好只是它们定位不同。ES-DE 是经典的桌面端游戏前端需要一台带显示器的电脑常驻运行库里跑着各种模拟器界面气氛感很足但它本质上是一个“本地前端”不是为资源集中到 NAS 而设计的。你人在外面想翻一下收藏或想在手机浏览器里看看封面它做不到。Batocera 则是把整个系统做成一个游戏主机镜像适合跑在一台专属小主机或旧电脑上更像一个“游戏机 OS”。可它不是一个常驻在 NAS 里给你做资源的服务管理收藏、刮削封面、远程浏览这些能力都偏弱Docker 化部署也不如 RomM 轻量。RetroArch 的核心是模拟器聚合平时当播放器用没问题但把它当游戏库管理工具就有点越界。它的界面更适合“放进去直接玩”而不是“对几千个游戏做分类归档和检索”。比较之后会发现RomM 是唯一一个把“NAS 上做资源库”作为第一优先级的方案可以容器化、目录结构简单、Web 界面天生适合“哪台设备都能看”。1.4 最终架构一览我的最终部署结构很常规老游戏镜像统一放在 NAS 指定共享目录按平台分成子文件夹在 NAS 上用 Docker 跑一个 RomM 容器挂载这个游戏目录容器从 IGDB 抓元数据生成数据库和封面缓存家里局域网内任何设备用浏览器访问NAS IP:端口即可这个架构里游戏文件本身永远不会被 RomM 改动它只是读取并索引所以就算哪天删掉容器、换掉软件文件依然原封不动躺在 NAS 上。类似“数据与视图分离”的思路让后续迁移成本降到了最低。2. 动手前先解决三个边界问题硬件、目录与合规2.1 跑 RomM 需要什么配置老 NAS 扛得住吗可以放心RomM 是这些年我在 NAS 上跑过的最轻量的服务之一。我做媒体服务器时跑 Jellyfin 转码CPU 会经常飙到 80% 以上跑 RomM 则大多数时间都是空闲状态只有扫描新库和刮削封面时会忙一阵。如果只是管理几千个 8 位、16 位主机游戏2 核 CPU / 2~4GB 内存的入门级 NAS 足够。我最初在老款双核 J 系列平台上跑内存给了容器 2GB扫描上百个游戏时依然稳定。真正吃资源的是前端的缩略图缩略RomM 做得很聪明封面会预生成小尺寸缓存因此浏览器访问时负载并不高。存储方面老游戏与电影不一样单个文件动辄几百 MB 到几 GB。一整套 GBA、SFC、MD 库加在一起往往也就几十 GB但如果连 CD 游戏都塞进去占用空间会明显变大。建议给这个共享目录划分时预留 500GB 到 1TB给未来扩展留出余地。机器是否支持 Docker 直接影响安装方式。群晖的 Container Manager、威联通的 Container Station、飞牛的应用中心、绿联之类的新兴系统都内置 Docker 环境理论上是通用可行的。如果你用的是纯 Linux 服务器比如 Debian/Ubuntu直接装 Docker 再跑一样的命令。2.2 目录结构提前规划能省八九成的扫描烦恼RomM 的数据库是按“平台”为顶层维度来组织的这意味着它强烈建议你先把游戏文件按所属主机平台分好文件夹。虽然它也能通过文件名推断平台但顶层目录清晰会大幅提高识别准确率。我实际在用的目录结构长这样rom-library/ ├── nes/ │ ├── Super Mario Bros. (World).zip │ └── Legend of Zelda (USA).zip ├── snes/ │ ├── Super Metroid (USA).zip │ └── Final Fantasy VI (USA).zip ├── gb/ ├── gbc/ ├── gba/ ├── n64/ ├── genesis/ └── psx/顶层目录的命名不需要严格照抄某个标准RomM 官方文档推荐的做法是与 IGDB 平台 slug 保持一致这样刮削时平台匹配最省心。但我实测只要目录名是常见英文单词比如nes、snes、gba、psx表现都很稳定。如果你已经有一堆叫“任天堂”“PS1”“超级任天堂”的中文目录也可以先不重命名扫描后再到后台做平台映射校正重点是把不同平台的游戏分开不要全部堆在同一个文件夹里。一个小建议如果你有大量 CD 游戏比如 PlayStation、Sega Saturn 这类由多轨道 bin/cue 组成的镜像尽量不要一个游戏丢一个文件夹。RomM 对单文件格式解析更好能合并成.chd或.pbp的尽量合并成单文件目录复杂度一降后面所有操作都清爽。2.3 游戏源文件的原则问题我不建议含糊跳过聊到老游戏收藏避不开的还有安全合规问题。RomM 本身是一个合法的开源工具但使用者要清楚自己往库里放的内容来源。我的建议是库里优先放自己有实体的备份、有明确授权允许个人备份的资料或者已经确认版权状态允许自由分发的文件。不到处搬运他人未经授权打包的资源。这里不是要说教而是现实里老游戏资源站点鱼龙混杂你下载回来的文件可能在解压时夹带别的东西放到 NAS 这个长期数据中心里等于给自己埋雷。另外从文件完整性看散落的资源质量差别很大一个异常文件可能导致刮削匹配失败甚至索引卡死。正规来源至少能保证文件名清晰、内容完整这一条比道德更实在直接决定了你的使用体验。3. 实操部署 RomM以 Docker Compose 为例3.1 在 NAS 上运行 RomM 的两种姿势RomM 官方提供 Docker 镜像安装方法不外乎两种一种是 NAS 系统自带的可视化 Docker 界面。以群晖为例打开 Container Manager搜索rommapp/romm镜像创建容器时填好端口和目录映射即可。这种方式适合不想碰命令行的用户但它把环境变量和目录映射分散在表单里出错后不容易排查。另一种是使用 Docker Compose 文件我强烈推荐。把配置写成一个docker-compose.yml所有端口、目录、环境变量一目了然以后重装或换机器只要把这个文件复制过去再执行一次docker compose up -d整个服务就复活了。这个优点在来回折腾 NAS 时特别有价值。如果你的 NAS 自带 Compose 功能比如群晖 Container Manager 的“项目”模块、飞牛的 Compose 应用直接把下面配置导入即可。如果没有可视化入口可以 SSH 到 NAS 后手动创建目录和文件。3.2 一份可以直接抄的 docker-compose 配置我先创建三个目录用来做数据持久化分别存放游戏文件、RomM 的资源和配置。如果你之前已经在 NAS 上分配好了游戏目录只需要把library那行改成实际路径。services: romm: image: rommapp/romm:latest container_name: romm restart: unless-stopped ports: - 8080:8080 volumes: - ./library:/romm/library - ./resources:/romm/resources - ./config:/config environment: - TZAsia/Shanghai - ROMM_AUTH_SECRET_KEYplease-change-me-to-a-random-string # 这两个留空也能先跑起来填了才能刮削封面 - IGDB_CLIENT_ID - IGDB_CLIENT_SECRET逐项拆开解释一下后面你会更容易 debug。ports里的8080:8080表示把 NAS 的 8080 端口映射到容器的 8080 端口网页访问地址就是http://NAS的IP:8080。如果你端口被占用可以改成8082:8080之类容器内端口不要动。volumes 是重头戏。./library是真正存放游戏镜像的目录RomM 的所有扫描都基于这里。./resources用于存放封面缓存、缩略图等生成资源这个目录本身并不重要但它代表“可以被重新生成的中间产物”建议和配置分开保存。./config保存数据库和设置这个目录必须长期保留相当于整套系统的灵魂。TZ设置为Asia/Shanghai避免时间显示错乱。ROMM_AUTH_SECRET_KEY一定不能留默认值这是用于签名认证的密钥哪怕只是单机局域网使用也建议随便敲一长串随机字符。IGDB 的 Client ID 和 Secret 首次部署时可以先留空先把服务跑起来验证目录结构后面再补上做刮削。3.3 启动后第一次访问先别急着管封面在docker-compose.yml所在目录执行docker compose up -d如果 NAS 上没有 docker compose 命令也可以用docker-compose up -d。第一次启动会拉取镜像耗时取决于网络状况和镜像大小等一两分钟再检查容器状态docker compose ps看到状态为 runninghealthy基本就成功了。接着浏览器访问http://NAS的IP:8080RomM 会提示你创建管理员账号这一步简单但密码一定要记住之后在 Web 界面管理库和用户权限都要用。此时进入首页大概率是空的不用急着刮削封面。先去设置里确认游戏目录是否映射成功然后点击“扫描库”按钮让它先做一次纯本地文件扫描。这样做的意义是先把结构跑通如果这一步有错误多半是目录映射错乱或权限不足值得先把基础问题排查干净再进入下一阶段。3.4 容器内存与权限的调优备忘跑了一段时间后我遇到过数据库连接中断最后排查出是容器内存限制太低SQLite 在写入大量元数据时被系统杀掉了。后来在 Docker 限制里给容器分配了 2GB 内存问题再没出现过。权限问题同样隐蔽。NAS 的共享目录通常有复杂的所有者体系容器内的进程以 root 身份运行时不一定会出问题但如果你在容器里用非 root 用户或者把游戏目录放在不同用户创建的文件夹下扫不出来就是常态。遇到扫描不到文件时第一反应应该是查容器用户对 library 目录是否有读权限而不是怀疑软件坏了。4. 刮削元数据让 RomM 第一次看起来像 Steam4.1 没有 IGDB 密钥就没有封面墙如果你跳过 IGDB 那一步直接扫描RomM 实际上也能正常浏览游戏但每张卡片都是一块灰色占位图只有游戏名没有简介、没有发售日期、没有类型标签。那它就只是个好看一点的文件管理器离“私人 Steam 游戏库”还差得远。RomM 的元数据来源是 IGDB 数据库这是游戏行业内覆盖面非常广的资料库。要拿到它的数据需要申请一组 API 凭证过程不复杂大概五分钟。先去 IGDB 的开发者页面跟着指引创建一个应用名字随意比如RomM-Home。创建后你能看到两串关键字符Client ID 和 Client Secret。前者相当于你的用户名后者相当于密码都需要填进 Docker 容器的环境变量里。一个有价值的提示客户端密钥有访问权限控制强烈建议不要把 Secret 写死在 docker-compose 文件里分享给任何人。如果只是个人 NAS 使用问题不大如果后期把配置同步到 Git 仓库一定要用.env文件配合环境变量引用避免密钥泄露。4.2 申请密钥之后的环境变量重载把刚才申请的 Client ID 和 Client Secret 填回 env 配置中刷新并重建容器docker compose up -d由于环境变量发生变化容器会重建但不用担心数据丢失因为数据库都存放在 /config 卷里。重建完成后再回到 Web 界面做一次完整扫描RomM 就会逐个匹配平台、查询 IGDB、抓取封面和文字资料。第一次刮削会比较慢尤其在收藏量大的时候可能一个平台要跑几分钟看着像卡住其实是在串行请求 API。心里有数就不会乱点。如果 IGDB 返回无结果常见原因是文件名信息和实际游戏标题不一致或者平台匹配错误。先检查这个游戏所属的平台目录是否正确再检查文件名是否含有过多机翻后缀。修正后再次扫描通常能补上。4.3 文件名规范直接影响刮削成功率RomM 的匹配策略说穿了就是拿你的文件名去数据库里做近似匹配。因此文件名的可读性越好刮削速度越快、准确率越高。我现在入库前会手动把文件改成更规范的格式举个实际例子不规范的命名zeldalinkpast_USA_SNES_en.sfc 相对规范的命名The Legend of Zelda - A Link to the Past (USA).zip(USA)或(Europe)这类地区标记对 IGDB 查重很有帮助能精确锁定版本。游戏全名尽量不要用拼音缩写RomM 识别英语原名最准。觉得麻烦的话至少保证文件没有多余后缀、没有错误的平台缩写。中文游戏名也不是完全不行刮不出来再手动编辑条目即可。数量少时在网页端手动改一下标题和封面所花的时间比维护一套自动化命名规则还要快。我的经验是只需对核心收藏做好规范命名边缘小游戏手动修正更划算。4.4 手动修正单人游戏的封面和简介即使命名很规范也有小概率匹配不到正确条目。出现这种情况时的处理流程很简单点进游戏的详情页找到编辑入口选择“重新搜索”或“手动关联”。搜索框可以输入英文名选定正确条目后 RomM 会同步更新封面、截图和简介。如果连 IGDB 也没有这个游戏的资料RomM 也允许直接上传本地封面图片这就给了玩家高度自定义空间。手动修正看着繁琐其实只对那几十个冷门或变体游戏才需要。批量入库一千个游戏自动刮削的准确率通常在九成以上剩下一百个集中花一个下午处理之后就一劳永逸。修完之后这个游戏库的完整度就已经超过绝大多数人本地散装的收藏了。4.5 把页面质感调得像 Steam 一样顺手当刮削完成后RomM 的页面已经具备基本“颜值”。它默认的横向封面卡片墙、鼠标悬停浮出简介、按平台下拉筛选都有那么一点 Steam 库的影子。你可以通过创建收藏夹来做自定义分区比如把“童年通关作”“出差消遣”“多人聚会”做成不同合集这样首页点开即是对应游戏墙比单纯按平台浏览更符合个人使用习惯。我喜欢把“最近添加”放在首页最前面。当新游戏入库后扫一眼这里能直观确认刮削是否成功不需要逐平台点进去看。这个小习惯大大降低了管理成本。5. 游戏装好之后怎么把它和“玩”打通5.1 管理器和模拟器的边界要分清楚经常有人部署完 RomM 后会问我在浏览器里点游戏封面为什么它不开始运行它不是模拟器RomM 的职责范围到“数据库和展示”为止。浏览器点击卡片后如果没有播放按钮不需要觉得被欺骗这只是因为它没有拼接浏览器端模拟器。想玩这些游戏通常有三条路。一是从 NAS 映射游戏共享目录到你的电脑或掌机再用本地安装好的模拟器打开对应文件。二是如果喜欢在网页里启动需要额外接入浏览器端模拟器方案这是一个独立的工程不在默认安装范围内。三是在 NAS 上同时跑一个专门为了游玩设计的游戏前端例如把同一个游戏目录复制给支持网络读取的模拟器系统让 RomM 和前端各自管一件事。实际使用时我建议方案三和方案一结合RomM 用来“逛游戏、做收藏、找文件”真正开玩时右键打开文件所在目录丢给 RetroArch 就能玩。把两者职责分开反而让流程更简单。5.2 用收藏夹做一套自己的“游戏分类学”收藏多了以后按平台浏览只是最基础的需求真正有趣的是用收藏夹建立自己的分类体系。RomM 支持自定义收藏夹我可以把 Game Boy 上那些在通勤路上玩过的游戏归为“通勤碎片”把需要认真看剧情的长篇 RPG 归为“周末专属”把和朋友聚会能热场的格斗类游戏归为“客厅派对”。这个分类的最大好处是不依赖你对游戏历史类型的记忆。多年以后你想找一个“小时候抱着被子玩的 RPG”打开收藏夹搜寻即可。分类建好之后RomM 首页的体验就真的和 Steam 库里精心整理过的收藏分区很像了只不过这次是你自己筛选出来的私人记忆而不是平台算法推荐的内容。5.3 手机、平板、客厅电视都能逛库RomM 的前端是响应式网页设计用手机浏览器访问时会直接展示适合触控的封面网格。躺在沙发上用平板翻着看收藏体验相当好。如果只是想在电视大屏上随机展示游戏墙也可以让客厅的电视盒子或智能电视浏览器直接访问同一个地址当个动态“海报墙”放着氛围感拉满。但要注意一点NAS 的访问权限别裸奔。我为 RomM 单独建了用户访问时要密码不开放任何匿名登录。即便是家庭局域网给 NAS 上的服务都设独立账号仍然是值得坚持的好习惯。6. 实操中踩过的那些坑整理成速查表6.1 扫描后一个游戏都看不到这是最常见的首跑故障。九成是因为 library 目录没挂载进容器或者容器里的路径与实际不匹配。检查 docker-compose 的 volumes 是否指向了正确宿主机路径。第二常见原因是权限容器用户对 NAS 共享目录没有读取权限尤其是群晖这类系统对新容器用户访问共享目录默认限制较严。先给容器赋权或确认目录权限后再扫描。6.2 游戏出现了但封面全是灰色占位图这个症状几乎都与 IGDB 密钥有关。先到 RomM 后台的环境变量页面确认 IGDB 的 Client ID 和 Secret 是否已填写还有一种是密钥填了但重建容器时没有正确读取 .env导致容器内环境变量还是空。最简单的排查方式是进入容器终端执行env | grep IGDB确认两串值是否都在。6.3 部分平台能刮到个别平台刮不到这种问题通常是平台目录名与 IGDB 的标准 slug 不匹配导致 RomM 拿着一个“未知平台”去 IGDB 查自然全空。解决办法是进入后台把当前平台手动关联到正确的 IGDB 平台编号。如果你不想做额外配置最省心的方式是从一开始就按我第二章提到的常见英文目录名来组织文件。6.4 文件名奇奇怪怪匹配得乱七八糟一些从老站点流传下来的 ROM 文件会带着发布组前缀或去重标记比如[TChi]、(PD)、[h1]。这些标记会让 RomM 在匹配时把名字理解为完全不同的内容。我的做法是入库前用批量改名工具把这类前后缀全部清理掉只保留游戏标准名和区域标记。偶尔遇到重名版本再用最详细的那个区域和版本标识来区分。6.5 升级容器后封面消失或数据库不匹配RomM 版本迭代速度不慢升级后偶尔会出现数据库 schema 不兼容的情况。所以升级前务必备份 /config 目录如果升级出问题至少可以回滚到旧镜像和旧配置。这不是 RomM 独有的问题所有自托管应用升级前都应该有同样的意识。我把整个常见问题整理成表方便你随时翻阅故障现象优先排查方向扫描后没有任何内容library 卷是否挂载、读取权限是否正确只有文件没有封面IGDB 环境变量是否缺失或未重载个别平台全部刮不到平台目录名是否与 IGDB slug 匹配某几个游戏一直匹配失败文件名不规范手动编辑重试容器启动后网页一直打不开端口冲突、容器状态未 running、NAS 防火墙升级后数据库异常回滚镜像先恢复 /config 备份6.6 大体积游戏处理的一个要点如果你的库里有大量 CD 镜像扫库时会发现文件解析有点慢因为 RomM 需要打开压缩包读取内部目录信息。为了减小体积和提升兼容性建议把普通 bin/cue 转成 CHD 格式。转换后单个文件体积会缩小RomM 解析起来也更快对你后续整理百 GB 级游戏库帮助明显。需要注意转换工具是独立软件操作前单独保留原始镜像不要原地覆盖。7. 后续值得继续折腾的几个方向我的这套 RomM 实例稳定运行了几个月后又开始折腾周边的自动化流程。现在新增一个游戏入库的完整链路大概三分钟先按平台丢进对应共享目录到 RomM 界面点一次扫描然后处理刮削不到的那几个冷门游戏顺手把它们拖进对应的收藏夹。长此以往库里的内容只会越来越完善。如果这个流程你已经跑通还可以考虑几个进阶方向。给 RomM 设置独立的备份计划把 /config 目录和 resources 目录定期同步到另一块硬盘或云存储上避免 NAS 硬盘损坏后多年整理的封面和元数据随之一同消失。更进一步如果你的 NAS 性能足够强还可以研究把前端服务与局域网里的其他游戏设备串起来做到真正在电视上像打开游戏主页一样浏览并启动游戏。最后我想分享一个个人习惯不要为了自动化而自动化。我最初尝试过写脚本扫描文件再自动重命名后来发现不如入库时顺手整理简单可靠。老游戏收藏的本质是“保存和回忆”RomM 已经帮你把回忆变得足够漂亮剩下的整理过程还是留一点人味最好。