同一个账号、同一个版本号，都不一定代表同一份状态。 今天有明确结果的开发工作主要在 MovieClaw Windows 客户端。昨天已经发布 1.0.0，今天继续处理实际使用中的观看状态、HDR 播放与更新问题，客户端推进到 1.0.3，最终发布的构建为 1.0.3(64.1)。这几件事都需要更准确地辨认对象。同一个账号可以在不同设备上同时播放，当前状态不能挤成一项；同一个版本号也可能重新打包，更新检查不能只比较版本文字。播放则需要区分画质切换失败、原画解码和显示模式，不能把所有报错都归为 HDR 不支持。今天的记录里，有代码修改、安装包发布和真机播放证据，也有尚未覆盖的服务端场景。下面把这些边界一起留下，避免把客户端完成误写成整条链路都已验收。当前观看按设备拆开，历史记录按内容合并观看状态的入口原来不够明显，用户也担心功能默认关闭时，客户端看不到其他用户或同账号其他设备的播放情况。这轮先补上首页“正在观看”入口，再调整状态的组织方式：同账号当前播放按设备拆分，历史则按影片或单集合并。两类信息回答的是不同问题。当前状态要说明有哪些播放正在发生；历史记录要归纳一个账号看过什么。把设备维度用于当前播放，不意味着历史也要为每台设备重复建立一份。随后又处理了离线用户的历史入口。“正在观看”改为胶囊按钮，已授权的离线好友及自己的账号可以进入最近观看记录。查看历史仍受授权条件约束，不是只要用户离线就能查看其记录。账号窗口的视觉对齐和开关颜色也作了修改，让入口和开启状态更容易辨认。客户端 1.0.3 与插件 1.0.0 的更新包已经发布，测试中的 Windows 客户端也已更新。但服务端旧插件仍需按说明更换，真实多设备场景还要在对应服务端版本下验证。客户端界面通过检查，不能代替这一项联调结果。HDR 播放恢复与显示模式要分别确认实际使用中出现了 HDR10 内容无法播放的反馈。这轮修复后，样本在 Windows 上完成真实播放，快进、跳转和暂停正常；后续又增加“原画播放”恢复按钮，降低画质失败时，可以保留进度切回本机解码，避免一次切换失败就失去继续观看的路径。这部分同时通过了 289 项测试和软件内更新检查。但截图里另一条 HDR 报错的触发原因尚未确认，不能因为样本恢复播放，就宣布所有 HDR 错误已经解决。原画能播、切换画质能播、报错原因已定位，是三个不同的结论。之后的播放截图显示，4K HEVC 使用 d3d11va 硬件解码，掉帧为 0，缓冲为 15.6 秒，mpv IPC 已连接且正在播放。这是当时播放状态正常的证据，不是长时间稳定性或所有片源兼容性的结论。界面显示的“HDR 转 SDR”也作了说明：在当前 SDR 显示模式下进行色调映射，属于正常处理，不代表正在进行原生 HDR 输出。判断播放状态时，要把解码、显示模式与错误提示分开看，才不会把正常的色调映射误认为故障。1.0.3 加上构建号，更新检查才能辨认重新打包今天多次修复都保持 1.0.3 版本号。如果安装包名称只有版本号，用户很难判断手里的文件包含哪一轮修改。用户因此要求，同版本重新打包时用括号标出构建号，并同步处理软件内更新与下载。先确认的播放包对应构建 61.1，之后把当前安装包整理为 1.0.3(64.1)。ZIP 内的安装程序也保留括号构建号，便于下载后辨认，校验文件与更新流程同时保持兼容。最终构建已经发布到 Windows 客户端仓库，本地源码同步，测试中的客户端完成更新。自动更新通知、下载和 SHA-256 校验经过实际检查，安装后显示“已是最新版本”。这里的完成依据包括发布产物与客户端更新结果，不只是仓库里出现一个新文件。最后还提交了 MovieClaw 上游 PR #815。记录结束时，检查全部通过，等待作者合并。提交和检查通过已经完成，但上游接纳尚未发生，不能把这份修改写成已进入官方版本。下一步仍要沿着真实使用检查今天留下三点认识。账号与设备是不同维度，当前会话和历史记录需要分别组织；版本号与构建号也有不同用途，重复打包要能追溯具体产物；播放截图能证明一个时刻的状态，却不能替代故障复现和长期测试。后续需要在服务端更新对应插件后验证多设备观看与授权历史，继续追查尚未确认触发条件的 HDR 报错，并观察画质失败后保留进度恢复原画的行为。构建发布还要等待上游 PR 的审阅与合并结果。今天已发布的是客户端构建，不能把这些待办一起算作完成。隐私说明本文只整理当天可核实的开发与验证结果，省略私人媒体名称、观看记录、账号信息、服务器地址、设备标识、本地路径和凭据相关细节。保留公开项目名、技术术语及必要的版本与测试数字，不包含完整代码或原始日志。
2026-10-12｜自然语言编程日记
今天有明确结果的开发工作主要在 MovieClaw Windows 客户端。昨天已经发布 1.0.0，今天继续处理实际使用中的观看状态、HDR 播放与更新问题，客户端推进到 1.0.3，最终发布的构建为 1.0.3(64.1)。
这几件事都需要更准确地辨认对象。同一个账号可以在不同设备上同时播放，当前状态不能挤成一项；同一个版本号也可能重新打包，更新检查不能只比较版本文字。播放则需要区分画质切换失败、原画解码和显示模式，不能把所有报错都归为 HDR 不支持。
今天的记录里，有代码修改、安装包发布和真机播放证据，也有尚未覆盖的服务端场景。下面把这些边界一起留下，避免把客户端完成误写成整条链路都已验收。
当前观看按设备拆开，历史记录按内容合并
观看状态的入口原来不够明显，用户也担心功能默认关闭时，客户端看不到其他用户或同账号其他设备的播放情况。这轮先补上首页“正在观看”入口，再调整状态的组织方式：同账号当前播放按设备拆分，历史则按影片或单集合并。
两类信息回答的是不同问题。当前状态要说明有哪些播放正在发生；历史记录要归纳一个账号看过什么。把设备维度用于当前播放，不意味着历史也要为每台设备重复建立一份。
随后又处理了离线用户的历史入口。“正在观看”改为胶囊按钮，已授权的离线好友及自己的账号可以进入最近观看记录。查看历史仍受授权条件约束，不是只要用户离线就能查看其记录。账号窗口的视觉对齐和开关颜色也作了修改，让入口和开启状态更容易辨认。
客户端 1.0.3 与插件 1.0.0 的更新包已经发布，测试中的 Windows 客户端也已更新。但服务端旧插件仍需按说明更换，真实多设备场景还要在对应服务端版本下验证。客户端界面通过检查，不能代替这一项联调结果。
HDR 播放恢复与显示模式要分别确认
实际使用中出现了 HDR10 内容无法播放的反馈。这轮修复后，样本在 Windows 上完成真实播放，快进、跳转和暂停正常；后续又增加“原画播放”恢复按钮，降低画质失败时，可以保留进度切回本机解码，避免一次切换失败就失去继续观看的路径。
这部分同时通过了 289 项测试和软件内更新检查。但截图里另一条 HDR 报错的触发原因尚未确认，不能因为样本恢复播放，就宣布所有 HDR 错误已经解决。原画能播、切换画质能播、报错原因已定位，是三个不同的结论。
之后的播放截图显示，4K HEVC 使用 d3d11va 硬件解码，掉帧为 0，缓冲为 15.6 秒，mpv IPC 已连接且正在播放。这是当时播放状态正常的证据，不是长时间稳定性或所有片源兼容性的结论。
界面显示的“HDR 转 SDR”也作了说明：在当前 SDR 显示模式下进行色调映射，属于正常处理，不代表正在进行原生 HDR 输出。判断播放状态时，要把解码、显示模式与错误提示分开看，才不会把正常的色调映射误认为故障。
1.0.3 加上构建号，更新检查才能辨认重新打包
今天多次修复都保持 1.0.3 版本号。如果安装包名称只有版本号，用户很难判断手里的文件包含哪一轮修改。用户因此要求，同版本重新打包时用括号标出构建号，并同步处理软件内更新与下载。
先确认的播放包对应构建 61.1，之后把当前安装包整理为 1.0.3(64.1)。ZIP 内的安装程序也保留括号构建号，便于下载后辨认，校验文件与更新流程同时保持兼容。
最终构建已经发布到 Windows 客户端仓库，本地源码同步，测试中的客户端完成更新。自动更新通知、下载和 SHA-256 校验经过实际检查，安装后显示“已是最新版本”。这里的完成依据包括发布产物与客户端更新结果，不只是仓库里出现一个新文件。
最后还提交了 MovieClaw 上游 PR #815。记录结束时，检查全部通过，等待作者合并。提交和检查通过已经完成，但上游接纳尚未发生，不能把这份修改写成已进入官方版本。
下一步仍要沿着真实使用检查
今天留下三点认识。账号与设备是不同维度，当前会话和历史记录需要分别组织；版本号与构建号也有不同用途，重复打包要能追溯具体产物；播放截图能证明一个时刻的状态，却不能替代故障复现和长期测试。
后续需要在服务端更新对应插件后验证多设备观看与授权历史，继续追查尚未确认触发条件的 HDR 报错，并观察画质失败后保留进度恢复原画的行为。构建发布还要等待上游 PR 的审阅与合并结果。今天已发布的是客户端构建，不能把这些待办一起算作完成。
隐私说明
本文只整理当天可核实的开发与验证结果，省略私人媒体名称、观看记录、账号信息、服务器地址、设备标识、本地路径和凭据相关细节。保留公开项目名、技术术语及必要的版本与测试数字，不包含完整代码或原始日志。