 tamakyi
|
3e16e78003
|
.ass 时间基准和视频对不上时按第一条弹幕自动对齐，并去掉重复的还原日志
1. 整场弹幕都被判「超出视频时长」，合并直接取消
上游原版录出来的 .ass 时间不是相对录制起点，而是相对弹幕客户端连上房间的时刻。
程序先开着、直播中途才开始录的场次，这份 .ass 的零点会比视频起点早一大截
（用户实测那份早了 7849.92 秒：955 条弹幕、跨度 5436.7 秒，视频只有 5456.9 秒）。
一律按「视频时间 = 弹幕时间 + 偏移」算的话，这 955 条全都落在 5456.9 秒之外，
于是「有 955 条弹幕超出了录播视频的时长，已跳过」→「弹幕文件里没有弹幕，取消手动合并」，
一分半的录播一条弹幕都合不出来。
这类偏移是能救的：跨度（末 - 首）5436.7 秒装得进 5456.9 秒，整体前移 7849.92 秒之后
覆盖 0 ~ 5436.7 秒、尾部正好空 20.2 秒 —— 和正常录播的尾部空隙（实测 6~20 秒）吻合，
是时间基准偏移，不是文件配错。
新增 fitDanmuToVideo，在探到视频时长之后、裁剪之前介入，触发条件收得很紧：
只有「按现偏移一条弹幕都用不上」**且**「弹幕跨度 < 视频时长」才整体平移，把第一条
对齐到视频起点，日志写明平移量、对齐后的覆盖范围和尾部空隙，并提示整体偏早或偏晚
可以在「偏移」里微调。其余情况完全保持原行为：只是一部分超出 → 照旧只丢尾部；
跨度本身就装不下 → 一条不留。这样不可能影响任何现在能正常合并的场次。
2. 「已从 xxx.ass 还原出 N 条弹幕」会打印两遍
页面的「检查」和真正合并会各解析一遍 .ass，而这条日志写在被复用的 parseAssFile 里，
于是同一句话出现两次，第二遍后面还跟着「已把 xxx.ass 还原成 xxx.jsonl」，看不出谁是谁。
把这两条日志从 parseAssFile 里摘出去（它改成返回坏行数 bad，由调用方决定要不要告警），
交给真正落盘那次的调用方 prepareDanmuSource(path, true) 打印，现在还会写明写成了
哪个文件；坏行警告统一走新增的 logAssBadLines，不再重复。
顺手给「最后一条弹幕超出视频总长」那条警告补了指引，说明合成时会自动对齐。
3. 测试里后台任务漏到用例结束之后
safeGo 原来直接把 goroutine 扔出去，用例结束它还在读全局配置，下一个用例开头一改配置，
-race 就判成数据竞争（而且报在后面的用例上，很难看出真凶）。把「怎么起后台任务」抽成
var runBackground，生产行为不变，测试里换成可等待的版本，清理时等它收工。
注意：这个竞争单独 -run 一个用例复现不出来（-race -count=3 也过），必须整包跑
go test -race . 才会在后续用例上报 race detected。
验证
- gofmt 无输出 / go vet 通过 / go test（182 个，18.5s）全过 / go test -race 整包跑 20 轮
（13 轮顺序 + 6 轮 -shuffle=on）全过 / staticcheck 无输出 / GOOS=linux go build 通过。
另：有一轮 -race 曾报过 FAIL、随后 20 轮都没能复现，怀疑是 TestDownloadAvatarCapsResponseBody
自带的抖动（它的断言依赖「服务端写不完 10MB」，受内核缓冲大小影响），与本批改动无关，
该文件本批也没动过；待单独确认。
- 反向验证从 32 项扩到 37 项全过（新增：自动对齐 / 只丢尾部不平移 / 跨度装不进不强平移 /
还原日志只打一次 / 后台任务可等待）；脚本新增单用例附加参数 "args" 与不带 -run 的整包用例。
- 用用户那份真实素材（955 条，7849.92 ~ 13286.59 秒，视频 5456.883 秒）端到端跑通：
不填偏移 + 5460 秒视频 → 日志「弹幕时间基准和视频对不上：955 条弹幕全部落在视频时长
（5460.0 秒）之外，最早那条在 7849.9 秒；已按「第一条弹幕对齐视频起点」整体前移
7849.9 秒（偏移 0.0 → -7849.9）」「对齐后弹幕覆盖 0.0 ~ 5436.7 秒，视频总长 5460.0 秒
（尾部空 23.3 秒）」，分 5 块渲染，exit=0，成片 5462.31 秒 / 23.3 MB。
再按 jsonl + 偏移反推「哪些时刻该有弹幕」，随机取 40 个应有时刻 + 20 个任意弹幕窗口都
不覆盖的空屏时刻，抽帧数白像素（白字黑底）：60/60 全对，跨块边界（1116/2435/3393/4408）
与最尾部 t=5435.7 都对得上。
- 60 秒小片新旧对照（真实 9 条弹幕、原始时间戳 7849.92 ~ 7908.7）：旧版「有 9 条弹幕超出了
录播视频的时长（60.1 秒），已跳过」+「jsonl 里没有弹幕」、无成片；新版自动前移 7849.9 秒、
9 条全画上、成片 34 MB。抽帧看轨迹仍是匀速 10 秒穿屏（danmuShowSeconds），
头像跟着文字同步走，没有回归。
|
2026-09-26 17:51:43 +08:00 |
|
|
tamakyi
|
9b9b3fa2cd
|
弹幕写盘出错不再被静默吞掉
审查发现：录制时每写一条弹幕都调用 os.File.Write / fmt.Fprintf，
但返回值一个都没接。磁盘写满、外接盘或网络盘掉线时，写入会失败而程序
毫无察觉 —— 照样打印「录制完成」、照样自动合并，最后拿到的成片缺了一大截
弹幕，界面上看不出是「缺了」还是「本来就没弹幕」。
1. 写入器记住写盘错误
danmuWriter 增加一个 err 字段：每条弹幕的 ass / nick.ass / jsonl 写入，
以及文件头的写入，都检查返回值。只保留第一个错误 —— 磁盘满了之后
每写一条都会失败，全记下来只会把日志刷爆，而第一个就足以说明原因。
2. close() 负责把错误交出来
三个文件的 Close 错误也要记：os.File 在部分系统上（NFS、某些网络盘）
是到 Close 才报出「写不进去」，只盯每次 Write 的返回值会漏掉这种情况。
getDanmu 里拿到错误就明确告警，并把这条记录标记成「弹幕文件写坏了」。
3. 写坏的本场跳过自动合并
光打一条日志不够 —— 照样会合成一个缺弹幕的成片。liveInfo 增加
danmuWriteFailed，finishPart 据此跳过合并，录播和弹幕文件都留着，
用户检查磁盘后还能手动合并。
已验证：
- 新增 4 个用例：
TestDanmuWriteErrorSurfacedOnClose（写入失败后 failed() 为真、
close() 必须把错误交出来、错误里能看出是哪个文件）、
TestDanmuWriteKeepsOnlyFirstError（只记第一个）、
TestDanmuWriteNoFalseAlarm（正常录制不能误判，这是加检查最容易踩的反向坑）、
TestFinishPartSkipsMergeWhenDanmuBroken（先跑一个「条件都满足应当合并」
的对照组确认测试本身有效，再验证标了写坏之后不合并）。
- 反向验证：把 jsonl 的两处 Write 错误改回丢弃，
TestDanmuWriteErrorSurfacedOnClose 立刻报「failed() 应为 true」。
- 测试踩到的两个坑（都记进注释）：替换 w.jsonl 前要先关掉原句柄否则
Windows 上临时目录删不掉；测试里没跑 initialize()，lInfoMap.info 是 nil，
直接赋值会 panic。
- gofmt / go vet / go build / GOOS=linux go build / go test / go test -race 全过，
全量测试连跑两次稳定。
|
2026-09-26 03:14:07 +08:00 |
|
|
tamakyi
|
e44dfa3a4a
|
补测试：重排对「本程序自己录的弹幕」零影响；多分段跨段冲突被一并解决
核实「弹道重排会不会影响正常录播的合并」时补的两个用例：
- recordjsonl_test.go：用真正的录制写入器 danmuWriter 造 500 条（密集，平均 0.22
秒一条），再按合并流程读回 jsonl 重排 —— 弹道变化 0 条、宽度变化 0 条。录制侧
写文件完全不经过 relayoutLanes，只有合并渲染前会重排，所以磁盘上的
.ass/.nick.ass/.jsonl 一个字节都不变，单段自动合并的成片和以前完全一致。
（顺带记下录制时确实会丢弹幕：500 条里 1 条因为 100 条弹道全满被丢弃，
jsonl 里根本没有它，重排也不会把它变出来。）
- layout_test.go：多分段（断流重连）拼接时 remapJsonlTimes 只改时间、保留各段
自己算的弹道，两段都从 0 号弹道起排，时间压缩到同一根轴后必然互相压。新增用例
先断言这种拼法本来就撞，再断言重排后冲突为 0 —— 这是重排唯一会改变输出的场景，
方向是变好，不是回归。
|
2026-09-25 18:28:52 +08:00 |
|