媒体链路接通与 Syncthing 扫描排障｜Codex 日报 · 2026-10-06 · archx

本文回顾本机 archx 在北京时间 2026-10-06 00:00—24:00 的主会话活动，按消息时间归属日期，包含旧会话的当天续接。共 3 条主会话记录，子代理与守护会话不参与总结。路径中的 ~ 表示本机用户主目录；远端路径会注明所在设备。文中命令用于追溯与手动复查。

这一天：恢复启动，接通媒体链路，追查同步停滞

10 月 6 日的三个主会话分别检查 Gen10 开机状态、完善 MoviePilot 与下载器链路、处理 QNAP Syncthing 扫描缓慢。正常启动和公网登录通过，并不意味着首次同步已经结束。

Gen10 启动正常，访问地址指向了不同设备

Gen10 于09:05启动，7个LXC全部运行，没有失败的系统服务，16TB盘正常挂载。Syncthing 的正确页面在存储容器，返回HTTP 200；此前访问的另一地址是QNAP源端，其管理页面超时不等于Gen10未启动。

当时两端同步连接存在，文件夹错误为零， from_ds218play 仍在同步。检查未重启服务、未修改配置、未删除源数据。

PVE挂载点为 /srv/qnap16 ，状态脚本位于CT105的 /root/sync_status.py 。原会话实际用过的检查可整理为以下命令，在PVE宿主机执行：

pct list
findmnt /srv/qnap16
pct exec 105 -- systemctl is-active syncthing-storage
pct exec 105 -- python3 /root/sync_status.py

下载器迁到16TB，MoviePilot与Jellyfin完成关联

qBittorrent、Transmission、aria2迁入16TB盘，旧数据保留，逐文件校验无差异。MoviePilot关联Jellyfin和下载器，硬链接整理验证通过，Jellyfin新增MoviePilot电影、电视剧库。

新增11个受Pangolin登录保护的HTTPS入口。PT站点与订阅尚未配置，没有启动自动下载。

用途	本机维护源，相对于 `~/meprojects/mevps/`
媒体服务	`gen10plus/media-sync/compose.yaml`
下载器	`gen10plus/torrent/compose.yaml`
aria2服务与示例配置	`gen10plus/torrent/aria2.service` 、 `aria2.conf.example`
媒体与下载器凭据	`gen10plus/media-sync-credentials.env` 、 `gen10plus/torrent-credentials.env`
入口凭据	`credentials/pangolin-credentials.env`
运维记录	`gen10plus/moviepilot-operations.md`

凭据文件当时为600权限。下面两条是当天实际执行的配置校验入口，只验证配置，不输出展开后的密钥，也不部署服务：

cd ~/meprojects/mevps
docker compose --env-file gen10plus/media-sync-credentials.env -f gen10plus/media-sync/compose.yaml config --quiet
docker compose --env-file gen10plus/torrent-credentials.env -f gen10plus/torrent/compose.yaml config --quiet

qBittorrent 公网未认证请求返回401，而经过Pangolin认证的会话返回WebUI 200。这个对照说明认证边界存在，但用户浏览器为什么没有自动转到登录页仍未完全确定，不能把任意401都当成后端故障。

Syncthing：换页与随机I/O是主瓶颈，监听额度是另一问题

09:42时，QNAP源端索引约完成23.62%，两分钟只推进约49 KiB。继续检查发现，可用内存约0.78 GiB，Syncthing驻留内存约1.4 GiB、换出约4.1 GiB，系统I/O等待约62%。机械盘很忙，但吞吐只有几MiB/s，符合换页与随机读取拖慢扫描的证据。

同时存在inotify监听额度告警。旧Downloads是一个独立任务，仅在新目录中排除Downloads并不会停用它。后续授权操作暂停了旧任务，将监听上限从262,144提高到524,288，并回读确认生效； Public/sync 的告警消失，另一目录仍有告警。

这是运行期设置，没有做开机持久化，重启后可能恢复。增加额度不能证明扫描速度翻倍，也没有解决所有换页压力。诊断记录为 ~/meprojects/mevps/xydr/qnap-192.168.31.219/syncthing-scan-diagnosis-20261006.md 。

下列是QNAP SSH shell中的只读复查示例，使用 /proc 读取实际值；本文不把运行期修改写成已存在的永久配置文件：

cat /proc/sys/fs/inotify/max_user_watches
free -m
vmstat 1 5

主会话与手动续接

在本机 archx 终端执行对应的续接命令：

QNAP 复制、媒体服务与同步维护

codex resume 01a102ec-bf3a-74c3-83d9-cbca947cea98

Gen10 启动状态核验

codex resume 01a10ed8-c4ac-73b3-842d-2fb8a802ece4

下载器、做种迁移与媒体整理

codex resume 01a0b53e-3024-7473-b617-7c7ab153af7b

这一天：恢复启动，接通媒体链路，追查同步停滞#

Gen10 启动正常，访问地址指向了不同设备#

下载器迁到16TB，MoviePilot与Jellyfin完成关联#

Syncthing：换页与随机I/O是主瓶颈，监听额度是另一问题#

主会话与手动续接#

QNAP 复制、媒体服务与同步维护#

Gen10 启动状态核验#

下载器、做种迁移与媒体整理#

相关日报#