PS5 玩家的截图管理问题我估计凡是玩过的都有体会游戏打了半年截图存了一堆真到想找某张图的时候翻主机相册翻到手指抽筋。官方导出的路子就那么一条先开自动上传再去官方 App 里一张张“保存到设备”然后在手机相册里被几千张图片淹没。我做的这个叫 AnyPS5 的小工具就是针对这条链路设计的它在电脑或 NAS 上运行自动盯住手机同步过来的 PS5 媒体目录按日期、类型、游戏标签去重整理最后生成一个可以搜、可以筛的网页索引。文章适合两类人看一类是只想省事的普通玩家照抄配置就能用另一类是有一定代码基础、想自己改逻辑的人我会把里面的设计思路和踩坑记录都讲清楚。1. AnyPS5 到底解决什么问题项目目标拆解1.1 主机相册的膨胀速度比想象中快得多我去年给一台 PS5 配了 2TB 的 M.2 固态空间是够了但相册里的内容反而更乱。PS5 截图默认是 PNG分辨率普遍是 3840×2160一张图大概 5 到 10MB自媒体如果开了 HDR 录制录像文件更大。我一个月大概玩 12 到 20 个小时每天随手按几次分享键一个赛季下来相册里能多出 300 到 600 个文件。这些文件在主机上的命名格式基本是纯数字前缀是拍摄时间戳看起来像2025-03-17 21-34-12.png实际没多少人会去手动重命名。官方导出流程本身也不友好。主机端只能设置“自动上传截图和录像”但这里的自动上传只是把媒体传到一个云端中转你想真正拿到本地还得靠手机上的官方 App 打开媒体页再逐条保存。选中多张批量保存已经算方便了问题是导出的文件会按时间顺序堆进手机相册完全丢掉游戏维度的分类。结果就是你的手机相册里混着一堆游戏截图、拍照模式作品、系统截图和录像想找某张特定截图只能凭记忆翻时间线。1.2 AnyPS5 的定位不做主机端修改只做“导出后的管家”这个项目从一开始就定了一条铁律绝不碰 PS5 系统内部不做任何绕过官方机制的操作。AnyPS5 的全部工作发生在这张截图已经通过官方渠道到达手机之后。你可以理解成它是一个“落地整理层”官方负责把媒体从主机送到你的手机或 NASAnyPS5 负责把你积攒的混乱文件变成有结构、可检索的媒体库。这样做的好处有三条。第一安全不用承担任何系统变更带来的风险第二通用PS5 不管哪个型号、哪个系统版本都能用因为工具根本不和 PS5 直接通信第三轻量AnyPS5 本身只耗一点 CPU 和内存跑在一台旧笔记本或者 NAS 容器里都游刃有余。它解决的不是“怎么把文件拷出来”而是“拷出来之后怎么不变成电子垃圾”。2. 技术方案拆解为什么这样选型2.1 不直连 PS5而是监听本地媒体目录立项之初我考虑过要不要通过局域网直接读取主机相册这样体验最顺玩家打开工具就能看到全部截图。但实际调研后放弃了。原因很直接PS5 没有对外开放稳定的相册访问协议任何非官方读取方式都意味着要走私有协议逆向或者依赖中间设备这套方案既不稳定也不合规而且主机系统每次更新都可能让工具失效。后来我换了个思路让数据流经过官方 App。手机 App 把截图保存到手机相册之后你可以通过 iCloud、Google 相册同步或 USB 传输把文件汇总到电脑/NAS。AnyPS5 只需要做一个“目录监视器”盯着目标文件夹有新文件进来就触发归档任务。这个方案没有复杂的网络权限问题跑起来非常稳。实测下来一周连续运行不重启不会崩也不会有内存泄漏比直连方案省心太多。2.2 技术栈选型Python SQLite Watchdog技术栈最终选了 Python主要原因是生态成熟、写起来快而且玩家自己二次修改的门槛低。核心组件有三个组件作用选型理由Python 3.10主程序语言跨平台文件处理生态完善watchdog目录监听基于 inotify/ReadDirectoryChangesW性能好SQLite媒体索引数据库单文件存储无需额外数据库服务Jinja2生成 HTML 索引页模板语法成熟方便做画廊页Pillow读取图片信息提取图片尺寸、缩略图生成imagehash感知哈希去重用感知哈希判断相似图避免误删为什么不直接拿现成相册软件我试过几款主流照片管理工具它们不支持游戏截图特有的“按游戏名分组”需求也没有针对 PS5 录像文件单独处理。现成软件的分类逻辑要么按相册要么靠人脸识别对游戏场景完全不适用。AnyPS5 的差异化就落在“游戏识别 录像归并 时间轴归档”这三个点上。2.3 游戏识别的三把尺子时间戳、元数据、OCR这是整个项目里最有意思的部分。一张截图从 PS5 导出来之后文件名里只有时间戳图片元数据也基本不包含游戏名。怎么知道这张图属于哪个游戏我用了三层识别逻辑第一层是“时间段映射”。很多玩家的游戏习惯是“一个时间段只玩一款游戏”你只需要在配置文件里记录“晚上八点到十一点在玩某游戏”系统就能按截图时间戳做初步归属。这个办法准确率高而且完全本地运算。第二层是图片元数据和尺寸特征。部分截图会保留设备信息和软件信息虽然游戏名通常缺失但分辨率、色深、HDR 标志可以作为辅助特征。比如《某竞速游戏》的拍照模式原图是 3840×2160而系统界面截图往往是 1920×1080这类特征能帮你区分“游戏内截图”和“系统截图”。第三层是 OCR 识别。如果截图顶部右侧有游戏标题水印或者画面里有明显的标题 UI可以用 OCR 提取文字。我集成的是 tesseract 引擎配合 whitelist 字符集和白名单词库只匹配你已安装的游戏列表。注意 OCR 不是百分百可靠我会把置信度低的文件放到uncategorized目录而不是强行归类。3. 从零搭建 AnyPS5完整实操过程3.1 环境准备与项目初始化在开始之前先梳理一下你的数据链路确保 PS5 的“设置 → 截图和录像 → 自动上传”已开启在官方 App 里把截图批量保存到手机相册再让手机相册同步到电脑或 NAS 的某个目录。AnyPS5 只在这个目录上工作。然后准备 Python 环境python3 -m venv anyps5_env source anyps5_env/bin/activate # Windows 下执行 activate.bat pip install watchdog Pillow imagehash Jinja2 python-dateutil我需要一个干净的目录结构实测下来这样组织最顺手anyps5/ ├── config.yaml # 配置文件 ├── games.csv # 游戏时间段映射 ├── main.py # 入口启动监听 ├── core/ │ ├── watcher.py # 目录监听 │ ├── archiver.py # 归档与重命名 │ ├── dedup.py # 去重模块 │ ├── ocr_engine.py # OCR 识别 │ └── gallery.py # HTML 索引生成 ├── media/ │ ├── unsorted/ # 原始文件导入区 │ ├── images/ # 按日期/游戏归档后的图片 │ └── videos/ # 录像归档目录 └── output/ └── index.html # 生成的媒体索引这里要提醒一下目录名里最好不要有中文和空格。虽然代码里做了路径兼容但 Windows 下依然容易出现编码坑直接用英文最省事。3.2 核心模块实现监听、去重、归档主程序入口逻辑很简单创建两个阶段先对现有目录做一次全量扫描然后进入监听模式。import time import yaml from core.watcher import MediaWatcher from core.archiver import ArchiveEngine def main(): cfg yaml.safe_load(open(config.yaml, encodingutf-8)) archive ArchiveEngine(cfg) watcher MediaWatcher(cfg[watch_dir], archive) print(AnyPS5 started. Press CtrlC to stop.) watcher.scan_existing() # 第一次全量扫描 watcher.start() try: while True: time.sleep(1) except KeyboardInterrupt: watcher.stop() print(AnyPS5 stopped.) if __name__ __main__: main()MediaWatcher用 watchdog 的Observer监听目录事件。这里有个关键细节不要直接处理on_created事件因为大文件比如录像复制到目标目录需要时间立刻处理会拿到一个不完整的文件。我采用的事件处理顺序是先记录事件等待文件大小稳定后连续两次检查间隔 5 秒大小不变再触发归档。from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import os import time class MediaWatcher(FileSystemEventHandler): def __init__(self, watch_dir, archive_engine): self.watch_dir watch_dir self.archive archive_engine self.observer Observer() def scan_existing(self): for root, _, files in os.walk(self.watch_dir): for f in files: path os.path.join(root, f) self._handle_file(path) def start(self): self.observer.schedule(self, self.watch_dir, recursiveTrue) self.observer.start() def stop(self): self.observer.stop() self.observer.join() def on_created(self, event): if event.is_directory: return self._wait_and_handle(event.src_path) def _wait_and_handle(self, path, tries5): last_size -1 for _ in range(tries): try: cur_size os.path.getsize(path) except FileNotFoundError: return if cur_size last_size and cur_size 0: self._handle_file(path) return last_size cur_size time.sleep(3) self._handle_file(path) def _handle_file(self, path): ext os.path.splitext(path)[1].lower() if ext in (.png, .jpg, .jpeg, .webp, .mp4, .webm): self.archive.process(path)归档引擎是核心中的核心。逻辑分成三步第一步用感知哈希判断重复第二步读取时间信息并匹配游戏映射第三步移动到目标目录、生成新的文件名。import os import shutil from PIL import Image import imagehash from datetime import datetime class ArchiveEngine: def __init__(self, cfg): self.unsorted_dir cfg[watch_dir] self.image_dir cfg[image_output] self.video_dir cfg[video_output] self.db self._init_db(cfg[db_path]) self.hash_cache set() def process(self, path): ext os.path.splitext(path)[1].lower() if ext in (.png, .jpg, .jpeg, .webp): self._process_image(path) else: self._process_video(path) def _process_image(self, path): hash_val self._get_image_hash(path) if hash_val in self.hash_cache: print(f[DUP] {path}) os.remove(path) return ts self._extract_time(path) game self._match_game(ts) category system if self._looks_like_system_ui(path) else game date_str ts.strftime(%Y-%m) target_dir os.path.join(self.image_dir, date_str, game, category) os.makedirs(target_dir, exist_okTrue) new_name f{ts.strftime(%Y%m%d_%H%M%S)}_{game}_{category}.png dest os.path.join(target_dir, new_name) shutil.move(path, dest) self.hash_cache.add(hash_val) print(f[OK] {dest}) def _get_image_hash(self, path): with Image.open(path) as img: return str(imagehash.phash(img))注意_get_image_hash用了感知哈希phash它能容忍压缩和尺寸变化。如果是同一张截图的缩略图和原图感知哈希值非常接近但可能不完全相等。我进一步用了“汉明距离 ≤ 6”的判断标准来判断相似图这里需要读取候选哈希来比较。正式版本建议把哈希放到 SQLite 表里用汉明距离进行比较而不只是存一个字符串集合。3.3 配置文件与游戏时间段映射任何没有配置文件的归档工具都是“半成品”。AnyPS5 的config.yaml长这样watch_dir: /mnt/nas/ps5_media image_output: ./media/images video_output: ./media/videos db_path: ./anyps5.db log_level: INFO hash_threshold: 6 ocr_enabled: true ocr_languages: eng # 系统 UI 特征用于过滤截图 system_ui_markers: - setting - trophy - home - control centergames.csv是游戏映射表这是我建议所有用户认真维护的东西。格式非常简单start_time,end_time,game_name 2025-02-01 20:00:00,2025-02-01 23:00:00,Stellar Adventure 2025-02-02 14:30:00,2025-02-02 17:45:00,Racing Masters 3 2025-02-03 21:00:00,2025-02-03 23:50:00,Stellar Adventure实际使用中我一周写一次这个 CSV 就行比在几千张截图里手动打标签快得多。如果你玩得很杂同一个晚上频繁切换游戏时间段映射就不太准了。这种情况下请打开 OCR 选项让系统尝试从截图上直接找游戏名。两个方法可以混合使用时间段映射结果优先OCR 结果如果和映射结果不同系统会打印一条警告并把文件放到needs_review目录等你有空时手动确认。3.4 建立 HTML 索引页让整理结果真正可检索整理到目录里只是第一步最终我还是想要一个能让我在手机、电脑上随时翻看的界面。AnyPS5 用 Jinja2 生成一个静态 HTML 文件按月份和游戏分组展示缩略图并支持标题关键词搜索。搜索功能用简单的前端过滤实现不依赖服务器所以这个 HTML 可以直接放在 NAS 上共享。生成索引的代码核心是查询 SQLite 中已归档文件再把结果传给模板import sqlite3 from jinja2 import Template TEMPLATE !DOCTYPE html html head meta charsetutf-8 titleAnyPS5 Media Index/title style body { font-family: sans-serif; margin: 20px; } .thumb { width: 320px; margin: 8px; display: inline-block; } .thumb img { width: 100%; } input { padding: 12px; width: 300px; margin-bottom: 20px; } /style /head body h1AnyPS5 Media Index/h1 input typetext placeholder搜索游戏名/日期... onkeyupfilter(this.value) div idgallery {% for item in items %} div classthumb>from concurrent.futures import ProcessPoolExecutor def scan_existing(...): files sorted(file_list, keylambda p: os.path.getmtime(p), reverseTrue) with ProcessPoolExecutor(max_workers4) as pool: pool.map(self._handle_file, files, chunksize20)这个改动之后2000 张图的首次扫描时间从将近 15 分钟降到了 6 分钟左右。如果你用的是 NAS 上比较弱的 CPU可以把并发数调到 2。4.4 常见问题速查表问题表现可能原因解决办法文件一直停在 unsorted 不归档文件大小不稳定等待次数耗尽在配置里调大wait_attempts和 sleep 时长录像被当成图片处理扩展名小写化没生效检查ext转换逻辑Windows 文件名大小写有时不统一游戏名一直是 UncategorizedCSV 时间段映射没匹配上打开 OCR 选项或检查 CSV 时间覆盖范围HTML 索引打开特别慢原图缩略图过大重新生成缩略图长边压到 480px归档后原始目录仍残留截图使用了复制而非移动确认shutil.move是否成功目标目录是否跨文件系统工具有时重复处理同一文件watchdog 触发了多次事件在内存中维护最近处理文件路径的 LRU 缓存10 秒内去重5. 进阶玩法把 AnyPS5 变成个人媒体中心的一环5.1 接入 NAS 与多端浏览我实际运行环境是一台旧笔记本装了 UbuntuAnyPS5 跑在 Docker 容器里监听的是 NAS 挂载目录。归档后的media文件夹通过 SMB/NFS 共享给客厅的电视、手机和另一台游戏电脑。HTML 索引文件放在同一共享目录里几台设备都能直接打开访问。这一步最值得做的配置是目录权限。我建议把media目录设为只读共享让 AnyPS5 容器拥有唯一写权限。这样即使电视或手机误操作也不会破坏整合好的媒体库。数据库文件anyps5.db则放到持久化目录容器重建后索引不丢。5.2 定时任务与手机端自动化的组合拳有 NAS 或者常开电脑的话可以给 AnyPS5 加一个定时任务每天凌晨两点跑一次全量扫描。这里有个小技巧用 systemd 的PathChanged触发器而不是Timer因为截图同步不一定每天都有PathChanged只有在目录变化时才唤醒程序比定时跑更省资源。# /etc/systemd/system/anyps5.service [Unit] DescriptionAnyPS5 Media Archiver [Service] ExecStart/home/user/anyps5_env/bin/python /home/user/anyps5/main.py Restarton-failure RestartSec10 [Install] WantedBymulti-user.target配套的anyps5.path文件[Unit] DescriptionWatch PS5 media folder [Path] PathChanged/mnt/nas/ps5_media Unitanyps5.service [Install] WantedBymulti-user.target这样配置后你日常只需要做一件事每周打开手机官方 App把攒下来的截图批量保存到手机相册然后让手机自动同步到 NAS。剩下的全部交给 AnyPS5。我在实际使用中发现只要坚持这个习惯一个月不手动清理主机相册媒体库依然整齐有序。最后再分享一个经验OCR 功能虽然锦上添花但真正稳定的还是那套“时间段映射 保守去重 日期归档”的组合。别为了追求全自动识别游戏名而去调成 100% 的自动分类留一个needs_review文件夹能让你在整理这件事上走得更远。 
长河君 · 2026/10/11 8:14:22 · 阅读 1.2k PS5截图管理神器AnyPS5：自动整理生成可搜索媒体库
PS5 玩家的截图管理问题我估计凡是玩过的都有体会游戏打了半年截图存了一堆真到想找某张图的时候翻主机相册翻到手指抽筋。官方导出的路子就那么一条先开自动上传再去官方 App 里一张张“保存到设备”然后在手机相册里被几千张图片淹没。我做的这个叫 AnyPS5 的小工具就是针对这条链路设计的它在电脑或 NAS 上运行自动盯住手机同步过来的 PS5 媒体目录按日期、类型、游戏标签去重整理最后生成一个可以搜、可以筛的网页索引。文章适合两类人看一类是只想省事的普通玩家照抄配置就能用另一类是有一定代码基础、想自己改逻辑的人我会把里面的设计思路和踩坑记录都讲清楚。1. AnyPS5 到底解决什么问题项目目标拆解1.1 主机相册的膨胀速度比想象中快得多我去年给一台 PS5 配了 2TB 的 M.2 固态空间是够了但相册里的内容反而更乱。PS5 截图默认是 PNG分辨率普遍是 3840×2160一张图大概 5 到 10MB自媒体如果开了 HDR 录制录像文件更大。我一个月大概玩 12 到 20 个小时每天随手按几次分享键一个赛季下来相册里能多出 300 到 600 个文件。这些文件在主机上的命名格式基本是纯数字前缀是拍摄时间戳看起来像2025-03-17 21-34-12.png实际没多少人会去手动重命名。官方导出流程本身也不友好。主机端只能设置“自动上传截图和录像”但这里的自动上传只是把媒体传到一个云端中转你想真正拿到本地还得靠手机上的官方 App 打开媒体页再逐条保存。选中多张批量保存已经算方便了问题是导出的文件会按时间顺序堆进手机相册完全丢掉游戏维度的分类。结果就是你的手机相册里混着一堆游戏截图、拍照模式作品、系统截图和录像想找某张特定截图只能凭记忆翻时间线。1.2 AnyPS5 的定位不做主机端修改只做“导出后的管家”这个项目从一开始就定了一条铁律绝不碰 PS5 系统内部不做任何绕过官方机制的操作。AnyPS5 的全部工作发生在这张截图已经通过官方渠道到达手机之后。你可以理解成它是一个“落地整理层”官方负责把媒体从主机送到你的手机或 NASAnyPS5 负责把你积攒的混乱文件变成有结构、可检索的媒体库。这样做的好处有三条。第一安全不用承担任何系统变更带来的风险第二通用PS5 不管哪个型号、哪个系统版本都能用因为工具根本不和 PS5 直接通信第三轻量AnyPS5 本身只耗一点 CPU 和内存跑在一台旧笔记本或者 NAS 容器里都游刃有余。它解决的不是“怎么把文件拷出来”而是“拷出来之后怎么不变成电子垃圾”。2. 技术方案拆解为什么这样选型2.1 不直连 PS5而是监听本地媒体目录立项之初我考虑过要不要通过局域网直接读取主机相册这样体验最顺玩家打开工具就能看到全部截图。但实际调研后放弃了。原因很直接PS5 没有对外开放稳定的相册访问协议任何非官方读取方式都意味着要走私有协议逆向或者依赖中间设备这套方案既不稳定也不合规而且主机系统每次更新都可能让工具失效。后来我换了个思路让数据流经过官方 App。手机 App 把截图保存到手机相册之后你可以通过 iCloud、Google 相册同步或 USB 传输把文件汇总到电脑/NAS。AnyPS5 只需要做一个“目录监视器”盯着目标文件夹有新文件进来就触发归档任务。这个方案没有复杂的网络权限问题跑起来非常稳。实测下来一周连续运行不重启不会崩也不会有内存泄漏比直连方案省心太多。2.2 技术栈选型Python SQLite Watchdog技术栈最终选了 Python主要原因是生态成熟、写起来快而且玩家自己二次修改的门槛低。核心组件有三个组件作用选型理由Python 3.10主程序语言跨平台文件处理生态完善watchdog目录监听基于 inotify/ReadDirectoryChangesW性能好SQLite媒体索引数据库单文件存储无需额外数据库服务Jinja2生成 HTML 索引页模板语法成熟方便做画廊页Pillow读取图片信息提取图片尺寸、缩略图生成imagehash感知哈希去重用感知哈希判断相似图避免误删为什么不直接拿现成相册软件我试过几款主流照片管理工具它们不支持游戏截图特有的“按游戏名分组”需求也没有针对 PS5 录像文件单独处理。现成软件的分类逻辑要么按相册要么靠人脸识别对游戏场景完全不适用。AnyPS5 的差异化就落在“游戏识别 录像归并 时间轴归档”这三个点上。2.3 游戏识别的三把尺子时间戳、元数据、OCR这是整个项目里最有意思的部分。一张截图从 PS5 导出来之后文件名里只有时间戳图片元数据也基本不包含游戏名。怎么知道这张图属于哪个游戏我用了三层识别逻辑第一层是“时间段映射”。很多玩家的游戏习惯是“一个时间段只玩一款游戏”你只需要在配置文件里记录“晚上八点到十一点在玩某游戏”系统就能按截图时间戳做初步归属。这个办法准确率高而且完全本地运算。第二层是图片元数据和尺寸特征。部分截图会保留设备信息和软件信息虽然游戏名通常缺失但分辨率、色深、HDR 标志可以作为辅助特征。比如《某竞速游戏》的拍照模式原图是 3840×2160而系统界面截图往往是 1920×1080这类特征能帮你区分“游戏内截图”和“系统截图”。第三层是 OCR 识别。如果截图顶部右侧有游戏标题水印或者画面里有明显的标题 UI可以用 OCR 提取文字。我集成的是 tesseract 引擎配合 whitelist 字符集和白名单词库只匹配你已安装的游戏列表。注意 OCR 不是百分百可靠我会把置信度低的文件放到uncategorized目录而不是强行归类。3. 从零搭建 AnyPS5完整实操过程3.1 环境准备与项目初始化在开始之前先梳理一下你的数据链路确保 PS5 的“设置 → 截图和录像 → 自动上传”已开启在官方 App 里把截图批量保存到手机相册再让手机相册同步到电脑或 NAS 的某个目录。AnyPS5 只在这个目录上工作。然后准备 Python 环境python3 -m venv anyps5_env source anyps5_env/bin/activate # Windows 下执行 activate.bat pip install watchdog Pillow imagehash Jinja2 python-dateutil我需要一个干净的目录结构实测下来这样组织最顺手anyps5/ ├── config.yaml # 配置文件 ├── games.csv # 游戏时间段映射 ├── main.py # 入口启动监听 ├── core/ │ ├── watcher.py # 目录监听 │ ├── archiver.py # 归档与重命名 │ ├── dedup.py # 去重模块 │ ├── ocr_engine.py # OCR 识别 │ └── gallery.py # HTML 索引生成 ├── media/ │ ├── unsorted/ # 原始文件导入区 │ ├── images/ # 按日期/游戏归档后的图片 │ └── videos/ # 录像归档目录 └── output/ └── index.html # 生成的媒体索引这里要提醒一下目录名里最好不要有中文和空格。虽然代码里做了路径兼容但 Windows 下依然容易出现编码坑直接用英文最省事。3.2 核心模块实现监听、去重、归档主程序入口逻辑很简单创建两个阶段先对现有目录做一次全量扫描然后进入监听模式。import time import yaml from core.watcher import MediaWatcher from core.archiver import ArchiveEngine def main(): cfg yaml.safe_load(open(config.yaml, encodingutf-8)) archive ArchiveEngine(cfg) watcher MediaWatcher(cfg[watch_dir], archive) print(AnyPS5 started. Press CtrlC to stop.) watcher.scan_existing() # 第一次全量扫描 watcher.start() try: while True: time.sleep(1) except KeyboardInterrupt: watcher.stop() print(AnyPS5 stopped.) if __name__ __main__: main()MediaWatcher用 watchdog 的Observer监听目录事件。这里有个关键细节不要直接处理on_created事件因为大文件比如录像复制到目标目录需要时间立刻处理会拿到一个不完整的文件。我采用的事件处理顺序是先记录事件等待文件大小稳定后连续两次检查间隔 5 秒大小不变再触发归档。from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler import os import time class MediaWatcher(FileSystemEventHandler): def __init__(self, watch_dir, archive_engine): self.watch_dir watch_dir self.archive archive_engine self.observer Observer() def scan_existing(self): for root, _, files in os.walk(self.watch_dir): for f in files: path os.path.join(root, f) self._handle_file(path) def start(self): self.observer.schedule(self, self.watch_dir, recursiveTrue) self.observer.start() def stop(self): self.observer.stop() self.observer.join() def on_created(self, event): if event.is_directory: return self._wait_and_handle(event.src_path) def _wait_and_handle(self, path, tries5): last_size -1 for _ in range(tries): try: cur_size os.path.getsize(path) except FileNotFoundError: return if cur_size last_size and cur_size 0: self._handle_file(path) return last_size cur_size time.sleep(3) self._handle_file(path) def _handle_file(self, path): ext os.path.splitext(path)[1].lower() if ext in (.png, .jpg, .jpeg, .webp, .mp4, .webm): self.archive.process(path)归档引擎是核心中的核心。逻辑分成三步第一步用感知哈希判断重复第二步读取时间信息并匹配游戏映射第三步移动到目标目录、生成新的文件名。import os import shutil from PIL import Image import imagehash from datetime import datetime class ArchiveEngine: def __init__(self, cfg): self.unsorted_dir cfg[watch_dir] self.image_dir cfg[image_output] self.video_dir cfg[video_output] self.db self._init_db(cfg[db_path]) self.hash_cache set() def process(self, path): ext os.path.splitext(path)[1].lower() if ext in (.png, .jpg, .jpeg, .webp): self._process_image(path) else: self._process_video(path) def _process_image(self, path): hash_val self._get_image_hash(path) if hash_val in self.hash_cache: print(f[DUP] {path}) os.remove(path) return ts self._extract_time(path) game self._match_game(ts) category system if self._looks_like_system_ui(path) else game date_str ts.strftime(%Y-%m) target_dir os.path.join(self.image_dir, date_str, game, category) os.makedirs(target_dir, exist_okTrue) new_name f{ts.strftime(%Y%m%d_%H%M%S)}_{game}_{category}.png dest os.path.join(target_dir, new_name) shutil.move(path, dest) self.hash_cache.add(hash_val) print(f[OK] {dest}) def _get_image_hash(self, path): with Image.open(path) as img: return str(imagehash.phash(img))注意_get_image_hash用了感知哈希phash它能容忍压缩和尺寸变化。如果是同一张截图的缩略图和原图感知哈希值非常接近但可能不完全相等。我进一步用了“汉明距离 ≤ 6”的判断标准来判断相似图这里需要读取候选哈希来比较。正式版本建议把哈希放到 SQLite 表里用汉明距离进行比较而不只是存一个字符串集合。3.3 配置文件与游戏时间段映射任何没有配置文件的归档工具都是“半成品”。AnyPS5 的config.yaml长这样watch_dir: /mnt/nas/ps5_media image_output: ./media/images video_output: ./media/videos db_path: ./anyps5.db log_level: INFO hash_threshold: 6 ocr_enabled: true ocr_languages: eng # 系统 UI 特征用于过滤截图 system_ui_markers: - setting - trophy - home - control centergames.csv是游戏映射表这是我建议所有用户认真维护的东西。格式非常简单start_time,end_time,game_name 2025-02-01 20:00:00,2025-02-01 23:00:00,Stellar Adventure 2025-02-02 14:30:00,2025-02-02 17:45:00,Racing Masters 3 2025-02-03 21:00:00,2025-02-03 23:50:00,Stellar Adventure实际使用中我一周写一次这个 CSV 就行比在几千张截图里手动打标签快得多。如果你玩得很杂同一个晚上频繁切换游戏时间段映射就不太准了。这种情况下请打开 OCR 选项让系统尝试从截图上直接找游戏名。两个方法可以混合使用时间段映射结果优先OCR 结果如果和映射结果不同系统会打印一条警告并把文件放到needs_review目录等你有空时手动确认。3.4 建立 HTML 索引页让整理结果真正可检索整理到目录里只是第一步最终我还是想要一个能让我在手机、电脑上随时翻看的界面。AnyPS5 用 Jinja2 生成一个静态 HTML 文件按月份和游戏分组展示缩略图并支持标题关键词搜索。搜索功能用简单的前端过滤实现不依赖服务器所以这个 HTML 可以直接放在 NAS 上共享。生成索引的代码核心是查询 SQLite 中已归档文件再把结果传给模板import sqlite3 from jinja2 import Template TEMPLATE !DOCTYPE html html head meta charsetutf-8 titleAnyPS5 Media Index/title style body { font-family: sans-serif; margin: 20px; } .thumb { width: 320px; margin: 8px; display: inline-block; } .thumb img { width: 100%; } input { padding: 12px; width: 300px; margin-bottom: 20px; } /style /head body h1AnyPS5 Media Index/h1 input typetext placeholder搜索游戏名/日期... onkeyupfilter(this.value) div idgallery {% for item in items %} div classthumb>from concurrent.futures import ProcessPoolExecutor def scan_existing(...): files sorted(file_list, keylambda p: os.path.getmtime(p), reverseTrue) with ProcessPoolExecutor(max_workers4) as pool: pool.map(self._handle_file, files, chunksize20)这个改动之后2000 张图的首次扫描时间从将近 15 分钟降到了 6 分钟左右。如果你用的是 NAS 上比较弱的 CPU可以把并发数调到 2。4.4 常见问题速查表问题表现可能原因解决办法文件一直停在 unsorted 不归档文件大小不稳定等待次数耗尽在配置里调大wait_attempts和 sleep 时长录像被当成图片处理扩展名小写化没生效检查ext转换逻辑Windows 文件名大小写有时不统一游戏名一直是 UncategorizedCSV 时间段映射没匹配上打开 OCR 选项或检查 CSV 时间覆盖范围HTML 索引打开特别慢原图缩略图过大重新生成缩略图长边压到 480px归档后原始目录仍残留截图使用了复制而非移动确认shutil.move是否成功目标目录是否跨文件系统工具有时重复处理同一文件watchdog 触发了多次事件在内存中维护最近处理文件路径的 LRU 缓存10 秒内去重5. 进阶玩法把 AnyPS5 变成个人媒体中心的一环5.1 接入 NAS 与多端浏览我实际运行环境是一台旧笔记本装了 UbuntuAnyPS5 跑在 Docker 容器里监听的是 NAS 挂载目录。归档后的media文件夹通过 SMB/NFS 共享给客厅的电视、手机和另一台游戏电脑。HTML 索引文件放在同一共享目录里几台设备都能直接打开访问。这一步最值得做的配置是目录权限。我建议把media目录设为只读共享让 AnyPS5 容器拥有唯一写权限。这样即使电视或手机误操作也不会破坏整合好的媒体库。数据库文件anyps5.db则放到持久化目录容器重建后索引不丢。5.2 定时任务与手机端自动化的组合拳有 NAS 或者常开电脑的话可以给 AnyPS5 加一个定时任务每天凌晨两点跑一次全量扫描。这里有个小技巧用 systemd 的PathChanged触发器而不是Timer因为截图同步不一定每天都有PathChanged只有在目录变化时才唤醒程序比定时跑更省资源。# /etc/systemd/system/anyps5.service [Unit] DescriptionAnyPS5 Media Archiver [Service] ExecStart/home/user/anyps5_env/bin/python /home/user/anyps5/main.py Restarton-failure RestartSec10 [Install] WantedBymulti-user.target配套的anyps5.path文件[Unit] DescriptionWatch PS5 media folder [Path] PathChanged/mnt/nas/ps5_media Unitanyps5.service [Install] WantedBymulti-user.target这样配置后你日常只需要做一件事每周打开手机官方 App把攒下来的截图批量保存到手机相册然后让手机自动同步到 NAS。剩下的全部交给 AnyPS5。我在实际使用中发现只要坚持这个习惯一个月不手动清理主机相册媒体库依然整齐有序。最后再分享一个经验OCR 功能虽然锦上添花但真正稳定的还是那套“时间段映射 保守去重 日期归档”的组合。别为了追求全自动识别游戏名而去调成 100% 的自动分类留一个needs_review文件夹能让你在整理这件事上走得更远。