Genteure

> 可以把弹幕姬打包成商店应用，然后发布到微软商店。 @Nukepayload2 但是还是有很多 Windows 7 用户的。 根据 www.danmuji.org 最近七天的 Google Analytics 统计，在占总共 86.78% 的 Windows 访客中： - 48.96% 是 Windows 10 - 48.73% 是 Windows 7 - 1.71% Windows...

用现在的 webhook 而不是直接执行命令有以下几个好处： - 不需要考虑命令行传参时特殊字符的转义 - 能传递的信息更多 - 能传递的事件类型更多 - 无法通过录播姬本身实现任意代码执行（主要针对命令行版） 考虑到的缺点有： - 需要多一个常驻进程 - 编写 HTTP 服务的难度可能比写直接运行命令的脚本更高一些 综合这些考虑，我觉得现有的 webhook 比较合适。 如果有什么其他的没有考虑到的地方也可以提。 issue 先 close 了，如果有必要的话再 reopen。

感觉可行性不是很高，首先录播文件大小不能提前知道，而且录播随时都有可能开始没法等一两分钟或更长时间写硬盘。 如果你有具体怎么实现的想法可以说一下。

@lindexi 据我了解 FileStream.SetLength 并不会预分配硬盘空间。 https://stackoverflow.com/a/41516109

我个人还是感觉实现起来会比较费劲。 之后一阵子的重点是重构大部分逻辑，这样的功能改动又大、需求又不很大、又和写入逻辑关系密切，就先搁置吧。。至少等到重构完之后再考虑了。

@821938089 你是用什么工具看出来有大量磁盘碎片的？还是猜的？

测试了一下两个直播间同时录，确实碎得一塌糊涂。 一个可能更可行的方案是，在内存里缓存一下输出内容，每 n MB 写一次硬盘，多个直播间的数据轮流写入而不是同时写入。 缺点 - 内存使用量会增加 - 数据写入不及时 - 如果软件崩溃，还未写入硬盘的数据会丢失 优点 - 应该能降低碎片数量（效果还需具体测试判断） - 不需要提前预分配硬盘空间 - ...因此对录到 Network Share 或 OneDrive 同步盘等位置的用户比较友好 - ...也不需要写 0 占位 - ...如果软件崩溃，不会留下一个全是...

我使用的检查 fragmentation 的工具： [contig](https://docs.microsoft.com/en-us/sysinternals/downloads/contig) [diskview](https://docs.microsoft.com/en-us/sysinternals/downloads/diskview) 之后重构 1.3.0 的时候会记着这个需求预留好接口，然后到 1.3.1 或者之后的版本再实现。

> 看上去 VMware 暂停的时候能直接把虚拟机的内存数据变成“已修改”，系统会在后台自动写进硬盘，此时关闭 VMware 并不影响。 @ysc3839 这段话是什么意思？没理解

写了一半的录播姬 1.3 已经 push 到了 `dev-1.3`，核心功能已经完成，WPF UI 还没改完但主要功能能用 如果有人有兴趣帮忙实现这个功能的话，实现这个功能需要： - 新建一个 class 实现 `BililiveRecorder.Flv.IFlvProcessingContextWriter` 或者 继承 `BililiveRecorder.Flv.Writer.FlvProcessingContextWriter`，在这个新的 class 里实现对磁盘碎片问题的优化 - 修改 `BililiveRecorder.Core\Config\V2\build_config.data.js` 添加一个控制写入模式的配置项 - 运行 `node build_config.js` 生成新的 C# 代码、然后运行一下格式化...