tamakyi
348e3bd675
档位改成「自动·第二高 + 实际档位」的下拉；手动合并也推送；头像缓存挪到程序目录
三件事：
1) 主播列表的录制档位
- 一律是下拉，不再有手填输入框。第一项「自动 · 第二高」（值 0）= 按这次读到的
档位排序自上往下取第二高（只有一档就用它，读不到档位表才退回最高档）；
后面依次列出实际档位。选最高/最低/中间某一档直接点它，手动选过之后
「自动」仍留在列表里，随时能改回去。
- 语义变化：0 不再被写死成某个具体码率。原来记录档位时会把「没选过」的主播
按第二档定下来（写进 config.json），现在只在取流时解析，所以主播换了档位表
也能跟着走；app 启动时的补齐逻辑（applyCachedDefaultQualities）随之去掉。
- 解析规则统一到 resolveQualityBitrate：0 = 第二高，>0 = 不超过它的最高档，
都比它高时退回最低档；「自动」项会把解析到的档位名带出来
（自动 · 第二高（当前 = 蓝光 4M））。/api/status 和档位接口都多了 qualityBitrate。
- 点「档位」按钮时先给一句「正在读取码率档位…」：主播没开播时服务端要重试三次
才放弃，约 5 秒，之前这段时间界面没有任何反应。
2) 手动合并完成也推送（这就是「MeoW 只在测试时成功」的原因）
- 原来只有自动合并调 sendNotify，手动合并从头到尾没推过，所以事件开着、渠道也通
却一直收不到。现在手动合并完成后同样按 mergeDone 事件推送两个渠道。
- 手动合并没有 uid，会拿成片名（再退到视频名）去对已有主播名，只有一个能对上时
才在文案里带上主播名，对不上就用「手动合并完成」。
3) 头像缓存挪到程序所在目录
- 原来存在「录播目录/avatar_cache」，换一次保存目录（甚至换盘）就要把同一批观众
的头像重新下一遍（一个头像可能 0.5MB）。现在统一放程序目录下的 avatar_cache。
- 旧位置作为只读回退：命中就搬过来（同盘改名，跨盘退回复制），不重复下载；
没被用到的旧文件留在原地，用到哪个搬哪个。
验证：
- 新增 avatar_test.go 两个用例（缓存路径、旧位置搬家）和 notify_test.go 的
TestManualMergeSendsMergeDoneNotify（真跑一次合并，断言 webhook 与 MeoW 各收到
一条 mergeDone，且从文件名认出主播）；qualities_test.go 改成新语义，新增
resolveQualityBitrate（7 种档位/码率组合）和 guessUIDByFileName。
- 端到端：把旧位置的头像缓存放在录播目录、头像地址指向连不通的端口，合并仍然成功
且画面里有那张头像（纯红像素 400 个），证明是搬来的而不是重新下载的；文件也从
录播目录搬到了程序目录。
- 浏览器：verify_streamer_br.py 重写成档位下拉的 20 项断言，verify_qualities.py
更新为新语义，两个都全过；verify_settings.py / verify_pick.py / verify_danmu_match.py
无回归；go test ./...、gofmt、go vet 干净。
2026-09-25 20:03:24 +08:00
..
2026-09-25 19:23:44 +08:00
2026-09-25 13:16:54 +08:00
2026-09-25 13:16:54 +08:00
2026-09-25 20:03:24 +08:00