 tamakyi
|
9684346067
|
清掉 5 个确认没人调用的遗留函数
staticcheck 的 U1000 一直报这 5 个，逐个核对过引用（含同名方法、测试、字符串调用、反射）：
- runFFmpeg：runFFmpegWith 的薄包装，没有任何调用点
- isLiveOn(uid int)：包级函数没人用，实际在跑的始终是 streamer.isLiveOn() 方法
- quitRecord：需要收尾的地方都直接 updateLiveInfo(..., isRecording = false)
- setLiveInfo：整体覆盖 liveInfo，早已被 updateLiveInfo（原地改部分字段）取代
- isRecording(liveID)：字段 info.isRecording 到处都在直接用
上一轮那个 jobActive 虽然也是 U1000，但它是「本该接上却漏接」的护栏（接回后
P0 的并发问题才解决），所以这次删之前特意确认这 5 个不是同类情况：它们都有
等价且更合适的现役替代实现。
验证：gofmt -l 空；go vet ./... 空；go build ./... 通过；go test ./... 全绿（11.3s）；
staticcheck -checks=all 的 U1000 归零。
|
2026-09-26 09:37:11 +08:00 |
|
|
tamakyi
|
8e82aa54c6
|
修第二批 P1：合并收尾、分块上限、确定性失败与 ffmpeg 路径归一
一、合并收尾只删真正进了成片的分段
prepareForMerge 中途有 4 处会回退成「只合并第一个分段」，而收尾仍按原分段列表
全删源视频 —— 后半场没进成片却照样被删掉，等于永久丢数据。现在 prepareForMerge
把「实际参与合并的源文件」一并返回（新增 used），收尾只删这些。
二、拼接中断不再在录播目录留几 GB 中间文件
concat 失败分支原来只有「被停止」那条路径删了 acfunlive_chunk_joined.*，
普通失败会把它留在录播目录，而且带着 chunkTempPrefix，界面文件列表里根本看不见。
三、把「被停止」和「拼接失败」分开
停止任务会杀掉 ffmpeg 让它非 0 退出，原来一律报成「拼接失败」，
卡片上显示的是失败而不是已停止；prepareForMerge 那里也统一改用 errors.Is 判断。
四、单块弹幕条数加硬上限（maxDanmuPerChunkHard = 200）
块尾会把「显示时间跨过块尾」的弹幕一并并入，弹幕密集时单块能膨胀到几百条。
一条弹幕在 -filter_complex 里约占 110 字节，几百条足以顶破 Windows 的
32767 字符命令行上限，表现同样是「合并失败且看不出原因」。到上限就把块尾
收到下一条弹幕出现之前，保证被挤到下一块的弹幕不会因为「整条早于块头」被丢弃。
五、确定性失败不再白重试三次
头像超出体积/尺寸上限这类失败重试多少次结果都一样，原来会白白把十几 MB 重新下三遍。
新增 noRetryError（runThrice 用 errors.As 识别）只标记这两个上限，网络类错误照旧重试。
六、ffmpeg 路径统一归一成绝对路径
PATH 里带「.」这类相对条目、或程序目录探测失败时，getFFmpeg 会返回相对路径。
合并时 ffmpeg 工作目录被改成输出目录，相对路径到那边就找不着了；而且 Windows 上
exec 会直接拒绝执行「相对当前目录」找到的可执行文件，报错还跟路径完全看不出关系。
验证：
- gofmt -l 空；go vet ./... 空；go build ./... 与 GOOS=linux go build 通过
- go test ./... 全绿（10.8s）；go test -race ./... 全绿（14.7s）
- 新增 chunks_test.go 10 个用例；6 项修复逐条反向验证（临时退回修复 → 对应测试确实失败）
- 51897 隔离实例上新产物实测：e2e.py 24 项全过；smoke_extra.py 34 项全过
（含并发合并返回 409 并报出在跑的任务名、口令失败后正确口令仍立刻可用、
超大头像被拒不误伤正常头像且只尝试 1 次、停止后无临时文件残留）
|
2026-09-26 09:35:51 +08:00 |
|
|
tamakyi
|
237fffa8fe
|
录制档位改成「最高/第二高/最低/自定义」四种相对偏好，没开播也能先设
上一版的下拉里列的是「这次读到的实际档位」，没读到档位表（没开播）时下拉里就只剩
一项，想预先设「我要最高档」或「最低档」都做不到。改成按「实际档位里的第几档」来选：
- 新增 `qualityPref`：top（最高档）/ second（第二高，默认）/ lowest（最低档）/
custom（取不超过给定码率的最高档，都比它高时退回最低档）。四种偏好任何时候都
在列表里，开播后自动对应到实际档位；读到档位表后把对应结果标在选项后面
（`第二高（蓝光 4M）`、`自定义（≤2500K = 高清）`）。
- `bitrate` 只在 custom 时有意义。`resolveQualityBitrate(tiers, pref, custom)` 统一
解析：相对偏好没有档位表时返回 0（取流退回最高档），custom 返回填的上限。
解析只在取流时做，所以主播换了档位表，偏好会跟着一起变。
- 老配置兼容：没有 qualityPref 时，`bitrate > 0` 当成 custom（就是原来的「码率上限」，
行为不变），`bitrate == 0` 当成默认的第二高；在 checkConfig 里补齐（不写盘，下次
保存自然带上）。`setBitrate` 相应换成 `setQuality(uid, pref, custom)`。
- 页面：选 custom 时旁边出现码率框，初始值就是**当前实际在用的那一档**（不会一切过去
就掉到最低档），回车或失焦即提交，填错给提示并回填服务端的值；从 custom 切到别的
档位不带 bitrate，服务端保留原值，改回来还是原来那个数。
- 设置区同步：新主播的默认档位也用同一套四项（`defaultQualityPref`），只有选自定义
才露出码率上限框（切过去会补一个能用的 3000，免得新主播默默用最低档）。
顺带修一个脚本抓到的真 bug：档位名传成了档位对象（`esc()` 里会 `.replace`），只要
档位表非空就会抛异常，而 refresh() 整段包在 try/catch 里 —— 表现是整个主播列表
变成空白且没有任何报错。现在取的是 `qs[i].name`。
测试：qualities_test.go 重写 TestResolveQualityBitrate（10 种偏好/码率组合）并新增
TestMigrateQualityPref、TestUpgradeQualityPrefs、TestSetQuality；verify_streamer_br.py
改成带迷你后端的假服务（POST 会真正落到假状态上），30 项断言全过；verify_qualities.py
25 项（含设置区与 config.json 往返）全过；verify_settings.py / verify_pick.py /
verify_danmu_match.py 无回归；go test ./...、gofmt、go vet 干净。
|
2026-09-25 20:42:22 +08:00 |
|
|
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 |
|
|
tamakyi
|
eda83dd1e3
|
主播列表的码率改为直播实际档位下拉，没选过时默认第二档
原来是一个手填的码率上限（Kbps），现在改成直播的实际档位（蓝光 8M / 高清…）：
- 读到档位后，主播那一行渲染成下拉，选完立即生效；正在录制时换档会自动重录。
- 没手动选过（bitrate 0）的主播按**自上往下第二档**定下来（如
蓝光 8M / 蓝光 4M / 高清 就选蓝光 4M，只有一档就用那一档），不会一上来就吃满
最高档；已经手动选过的永远不动。
- 档位要开播后读直播源列表才知道，读到以后（录制开始时、或页面点「档位」按钮）
缓存进 config.json 的 qualities，所以没开播也能看和改；启动时会把「有缓存但还
没定过码率」的主播按第二档补齐。
- 从来没读过档位的行仍然是手填输入框，旁边多了个「档位」按钮去直播间接一次。
后端：新增 `GET /api/streamer/qualities?uid=…`（同一主播 10 秒内只读一次），
`/api/status` 的每个主播多了 `qualities`（按码率从高到低）和 `qualityName`；
抽出 `newStreamInfo()`/`fetchStreamQualities()`，`getStreamURL()` 取流时顺手缓存
档位，并在 bitrate 为 0 时改用刚定下来的默认档位（否则还是最高档）。
档位相关的纯逻辑放在 config.go：`sortQualitiesDesc` / `defaultQualityBitrate` /
`qualityNameFor` / `sameQualities` / `setStreamerQualities` / `applyCachedDefaultQualities`。
测试：qualities_test.go 7 个用例（排序、默认第二档的 5 种档位数、档位名匹配、
写配置时不覆盖手动选择、启动补齐、JSON 存取往返）；浏览器实测 5 组断言全过
（下拉选中当前档位、换档服务端立即变、无档位时保留输入框+按钮、启动默认第二档、
手填仍可用），verify_streamer_br.py / verify_pick.py / verify_settings.py 无回归；
go test ./...、gofmt、go vet 干净。
|
2026-09-25 19:42:47 +08:00 |
|
|
tamakyi
|
ed4e47e305
|
init
|
2026-09-25 13:16:54 +08:00 |
|