Release XDownload v2.10.0 · MuZiCul/XDownload

🚀 v2.10.0 带来两项修复：下载历史去重（同一条视频只保留一条最新记录，重下自动替换旧记录）与 ffmpeg 更新检测修复（不再"更新完还反复提示"，也不会白下约 195MB）。

🐛 关键修复

现象：某条视频下载失败后重新下载成功，下载历史里却同时留下两条卡片（一条失败、一条成功），失败那条怎么也去不掉。
根因：历史记录的唯一键 video_id 有两个来源——批量下载 / 深链 / 书签同步写入的是 URL 里的推文 status id，而单链下载 / 历史页重新下载写入的是 yt-dlp 解析出的媒体 id。两者多数情况相同，但偶尔指向不同 id，于是同一条视频被写成两条记录，重新下载自然覆盖不掉另一条键上的旧记录。
修复：全链路统一历史键为推文 status id（新增 utils::url::history_key 作为唯一规则）：
- 入队时归一化任务 video_id；
- 解析视频信息时，回传给前端的 id 也归一化，保证「已下载」判断、打开文件位置、重新下载都落在同一个键上；
- 写历史时再次兜底归一化，任何入口都不会再产生第二个键。
效果：重新下载成功 → 旧的失败记录被替换；重新下载仍失败 → 只保留最新那次失败记录。

现象：更新 ffmpeg 之后仍持续提示有 ffmpeg 更新；再点一次更新会重新下载约 195MB，提示依旧。
根因：旧逻辑把两个语义不同的时间直接比较——
- 远端基准 = BtbN release 的 published_at（发布完成时刻）；
- 本地基准 = bin/ffmpeg.exe 的 mtime，而解压代码刻意把它恢复成 zip 内文件时间（构建打包时刻）。
构建产物要打包上传完（一次构建 49 个资产、2GB+）release 才发布，published_at 恒晚于 zip 内文件时间（实测差 49 分钟）。于是只要装的是当时的最新版，就永远判定"有更新"。
修复：判定改为两级指纹比对：
1. 资产 ETag 优先：向远端资产发一次请求只读响应头（不下载 body），ETag 与"上次安装时记录的 ETag"比对，不同即内容变过；
2. 资产上传时刻保底：取不到 ETag 时，用该资产在 GitHub API 里的 updated_at 与"本地安装时刻"比较；老版本升级上来、没有安装记录时用 ffmpeg.exe mtime +6 小时容差兜底（覆盖发布延迟）。
安装 ffmpeg 成功后会写入安装时刻 + 资产 ETag（存在 config/data.db），所以"刚装完还提示有更新"不会再出现。

启动时执行一次幂等迁移（写 config 表的 marker，只跑一次）：把已有记录的键统一为推文 status id，同一条视频的多条记录只保留最新的一条，其余删除并写入日志。
迁移失败只告警、不阻塞启动；重跑安全（marker 未写入时会重新执行）。

设置页点「更新」时会先强制刷新一次检查：后端确认"已是最新"则直接提示已是最新并跳过下载；只有确实有新构建才会开始下载。（用户主动"重新下载"仍照常执行。）

首次启动会自动下载 yt-dlp + ffmpeg，也可以手动放入 bin/ 目录。