Genteure
Genteure
这个是之前有一天我自己用的时候遇到的，因为觉得一般也不会有人在断网的时候添加房间，遇到这个问题的概率很小，就一直搁置着。 我还没有去梳理问题具体在哪，但我感觉你说的这个方案应该不能解决这个问题。 这个bug的原因是在请求直播间信息之前就连接弹幕服务器了，实际应该保证在连接弹幕服务器之前至少成功请求过一次直播间信息。
@lindexi DriveInfo 支持 UNC 路径吗？Volume 是可以 Map 到一个 Path 而不是 Drive Letter 上的，Drive Info 支持根据路径读取剩余空间信息吗？ 有很多录播姬用户是直接录到 Network Share 上的。 因为这些细节问题，再加上这个功能必要性不是很大，所以搁置到现在都没实现。
> 因为这算是非 power user 很难解决的一个痛点 痛点具体是指什么？ 目前 1.3 进入最终的完善阶段了，1.3 的第一个正式版不打算再加新功能了，就差翻译界面和一点细节调整就可以发布了。这个功能可以在 1.3 的一个小版本里和 #184 一起实现。 如果要弹通知的话，考虑写一个管理通知的东西，把开播通知之类的也一起实现了。
在 https://github.com/Bililive/BililiveRecorder/commit/7dbcbb4069cea6d577bc8f448fa90762f66f4ec6 里实现了检测网络接口，判断使用的是否是 WiFi 并输出提醒到日志。 等以后做了通知系统之后再接到通知系统上。
现在没有这个功能，之后会加
duplicate of #114 今天晚点加上
收到邮件反馈又有一个人遇到了此问题，看起来也是 SRT 60FPS 44.1KHz 猜测：可能时间戳是正确的，但是音频的位置（发送顺序）比视频靠后了一位。又因为 60 FPS 下一帧是大约 16 ms，所以计算出的偏移量大概是 16 ms。 --- SRT 60FPS 48KHz 的情况下，目前的修复逻辑会持续计算出偏移量 16 ms 目前我还没能成功复现 SRT 推流导致音视频数据错位的情况，没法确认到底是数据的顺序错了还是相对时间戳错了，猜测可能是顺序错了。
@77580 总时长显示 00:00 是符合预期的，有的时候能显示出来总时长也是正常情况，这个和是不是自动结束的没有直接关联，是由直播服务器给的数据决定的。 Edit: 好像有可能有关联，不过也算是符合预期吧
看起来是因为直播服务器给的直播数据没有关键帧，导致的直播数据全部攒在内存里。 考虑到这个是以不受支持的方式录的 HEVC 流，暂时忽略不管了。 如果要“修”的话估计也就只是在 Tag 分组那里设置一个上限，超过上限之后直接断开录制。
和这个地方有关，回头可以改一下 https://github.com/BililiveRecorder/BililiveRecorder/blob/05897e9533e5805822b9683400e46d06058fd821/BililiveRecorder.Flv/Parser/FlvTagPipeReader.cs#L246  