Bilirec 配置入门：录制哔哩哔哩直播间
Bilirec 用于录制哔哩哔哩（bilibili，B站）直播间：给程序一个 B站房间号，可以手动保存正在进行的直播，也能订阅房间，在检测到开播时自动录制。它接收的是 B站直播流，保存媒体与可选的弹幕等互动记录，文件写到运行程序的设备上。
程序可以运行在 Windows、macOS 或 Linux 上，再由浏览器中的 Web 管理界面连接后端、配置房间和查看文件。哔哩哔哩是录制对象所属的平台，操作系统是后端运行环境；本文中的"平台账号"指 B站账号，后端访问账号则用于保护自己的录制服务。排查连接问题时，先分清这几层关系。
本文围绕 v0.3.0 的二进制启动、配置来源和检查顺序展开，依据官方发行与文档材料，不提供本机运行结论。示例中的房间号只表达接口格式，实际操作应替换为自己获准保存的 B站直播间。
确定运行对象和文件类型
bilirec 的发行附件包含 Windows 可执行文件、Linux amd64/arm64、macOS amd64/arm64，以及 Android arm64-v8a/x86_64 原生动态库。它们服务于不同运行方式；Android 库不是 APK，不能与独立 bilirec-mobile 客户端混用为同一种安装资源。
Linux amd64 的官方启动写法如下。ARM64 与 macOS 对应选择另一个文件名；Windows 文档使用双击可执行文件的方式。执行权限和系统架构都要先对应，不能靠改扩展名让一个平台附件变成另一个平台程序。
bash
chmod +x bilirec-linux-amd64
./bilirec-linux-amd64后端默认在本机 8080 端口提供服务。浏览器连接使用 http://localhost:8080 时，localhost 指浏览器所在设备。后端在远程机器上而浏览器仍填本机地址，会先出现连接问题，不应直接重装程序或更换画质配置。
管理前端入口是 https://app.bilirec.org/，在登录页填写后端地址。前端负责管理已有后端，访问页面不会在设备上自动安装或启动录制服务。HTTPS 页面连接远程后端须考虑 HTTPS；本机 HTTP 与远程 HTTP 的连接条件不同，不要把本机成功当成远程部署已经打通。
界面图用于辅助辨认选项；文档未标明截图版本，本文未进行本机运行测试。
图：填写后端地址和访问账号。
先查配置覆盖，再查变量本身
二进制加载配置涉及三层：当前工作目录的 .env.local、可执行文件目录的 .env，以及覆盖文件值的环境变量。首次运行会生成 .env。Docker 则仅用环境变量，不按二进制方式读取这些文件。
这意味着"修改了文件"与"运行进程采用了这个值"不是同一件事。排查时记录启动目录、修改的是哪个文件、是否还有同名环境变量。若从另一个目录启动程序，也应重新确认工作目录文件的影响。
v0.3.0 移除了部分旧别名。旧配置中的 CONVERT_FLV_TO_MP4 应改用 CONVERT_TO_MP4，DELETE_FLV_AFTER_CONVERT 对应 DELETE_SOURCE_AFTER_CONVERT，BACKEND_HOST 对应 PUBLIC_BASE_URL。检查迁移时应搜索旧名称，而不是只核对新的默认配置。
用户名密码保护后端访问；B 站登录则影响平台账号状态。前者通过 USERNAME 与 PASSWORD 配置，后者可采用 Controller、启动扫码或匿名模式。服务验证与平台登录各检查一次，才有条件继续判断直播流取得是否正常。
用一个任务验证接收与保存
图：录制与回放流程示意。
连接管理界面后，输入 B站直播间房间号，在确认页选择画质、流格式、音频、弹幕和录制时长。先创建一个有明确停止点的任务，有助于同时检查录制开始与结束后的文件处理。
API 也提供启动和停止接口。官方快速开始给出的基础形式是：
bash
curl -X POST "http://127.0.0.1:8080/record/12345/start"
curl -X POST "http://127.0.0.1:8080/record/12345/stop"这两条命令展示的是接口顺序，执行前应换成实际房间号，并满足自己的服务认证设置。界面和 API 都能管理任务，但接口返回与最终媒体可播放之间仍有保存和处理环节，需要继续检查文件结果。
建议把验收顺序写成：任务开始后查看状态；停止后查看媒体文件；打开回放确认音视频；若开启互动记录，再看对应弹幕文件和回放效果。这样能分开"任务创建失败""媒体未保存""播放不支持"和"互动记录没有开启"等不同问题。
画质属于请求选择，不代表直播端一定提供对应档位。流格式设置则决定允许尝试的范围。首次验证不要同时堆叠高画质、多路录制与转换，先拿到一份能解释来源的输出，再逐项改变条件。
图：确认这一场的时长、画质、格式和互动记录。
区分重连、分段和转换
v0.3.0 新增拉流空闲超时，STREAM_IDLE_TIMEOUT 默认二十秒，设为零可以关闭。长时间没有新数据时会断线重连。它处理的是连接卡住的情况，不能修复上游已经没能接收到的全部内容。
FLV 时间戳修复、断流重连及自动分段也是项目的既有能力。不同流格式的轮转行为不完全相同；出现多段文件时先对照直播变化与连接日志，确认每段的时间和播放情况。不能仅凭"文件有好几个"就把它当成异常重复下载。
转换需要独立准备依赖。使用本地方式要有 FFmpeg，云端方式使用 CloudConvert。v0.3.0 中，开启 CONVERT_TO_MP4 后，仅音频录像会转换为 m4a，视频转换为 mp4。录制成功但转换未完成时，应把原始媒体与转换任务分开排查。
Webhook 默认不发送，填写 WEBHOOK_URLS 后才启用。该版兼容录播姬 v2 事件，失败最多重试三次。若开启内置转换，FileClosed 等转换成功后才针对成品发出；对接 biliLive-tools 时官方要求保持 CONVERT_TO_MP4=false。这关系到处理流程的归属，不能两边都配置后又以"收到事件"判断最终文件已完成。
为持续录制安排存储策略
订阅房间后分别配置自动录制和通知。手动开录与房间自动开录的时长设置有区别，应检查当前任务使用的参数来源。先用一个房间验证自动行为，再增加房间数量，能减少配置和资源同时变化造成的混淆。
空间不足删旧录像是 v0.3.0 的可选能力，默认关闭。开启后会处理该房间最旧媒体及同名弹幕；它不会跨房间替你均匀清理空间，删完仍不足也不会继续开录。若要保留重要录像，备份和筛选应先于启用轮换。
Docker 用户应持久化记录、秘密信息与数据库三个目录，不能只挂录像目录就以为全部运行状态都已保留。官方示例使用 latest，但 latest 会随发布变化；固定版本教程不应把它直接标为 v0.3.0 的镜像证据。
文件页的 only_media 过滤只显示音视频及目录，能减少互动记录对浏览的干扰，但不会让那些文件消失。排查"列表里看不到弹幕文件"时，先看筛选状态，再检查实际对应记录；不要把媒体筛选结果误当成完整文件清单。备份和移动也应包括需要保留的互动文件。
最后再考虑并发。官方树莓派测试有明确的设备、容器限额和画质条件，不能据此承诺任意旧设备可录多少路。实际规划需要分别观察接收直播、磁盘写入与媒体转换的负担，按任务增加范围。
GitHub 仓库：https://github.com/bilirec/bilirec