nICEnnnnnnnLee/BilibiliLiveRecorder

测试douyin时，出现了一个空档，程序不工作的现象。

HarlockHomes opened this issue · 4 comments

HarlockHomes commented

过程：

java -Dfile.encoding=utf-8 -jar BiliLiveRecorder.jar "debug=true&check=false&liver=douyin&id=************&qn=-1&filePeriod=60&stopAfterOffline=false&retryIfLiveOff=true&maxRetryIfLiveOff=0&retryAfterMinutes=3&retry=9999&fileName={startTime} {name}-{seq}&"

除了直播ID不同，录制的命令是一样的参数。直播间A在正常录着时，另开命令启动开始录B。
浏览器中的B的直播还在继续，我看B的下载文件的扩展名已经变成了flv，大小无变化，也没有新的part文件。我才觉得不对，就去看B的cmd窗口里，显示已下播，正在处理。
看文件夹里的录制的文件时间显示距离最后录制已经过去20分钟，它并没有按参数设置中的，每3分钟一检测是否开播。

我觉得很奇怪，按了几下回车，看到提示是 Stop或q退出。我没有继续，而是另开cmd窗口继续录制，过了几分钟，B窗口里终于出现了检测并开始录制。

过程中A的录制都正常。

这个现象挺奇怪的，赶忙写到这里来。

HarlockHomes commented

下播结束录制后很久，我看了眼窗口，又有那个正在处理的提示，
image

nICEnnnnnnnLee commented

没有在录制的时候打印正在处理...很正常，

重点是3分钟后，也就是大约18个正在处理...后，有没有再显示3.0分钟后重试

HarlockHomes commented

今天的直播我看了，程序判断已经下播，是因为主播给手机充电的动作导致，但浏览器里只是画面震动一下。

昨天停了20分钟没有检测，手动回车后，程序才进入到检测进程。——这是事实，但今天没有复现。

今天的下播后检测是正常发生的，虽然是为主播给充电造成的波动，并非真的下播了。
检测是正常地发生在它判断下播后的3分钟。

因此，我建议程序能在这种刚刚判定为下播时，在其后的一段时间内，主动按x秒间隔，去重新检测。这样就可以避免这种假下播造成的间隔太久。希望nICEnnnnnnnLee 得以考虑这个设定。

nICEnnnnnnnLee commented

  • 逻辑上不存在停了20分钟没有检测，然后程序又能开始正常检测的可能。
    除非鼠标不小心在命令行窗口选择了部分文字，或其它类似操作阻塞了输出，停滞了后续相关代码运行。

  • 程序最初的设计仅仅只是实现支持多平台的单次录制，各种需求加到现在耦合很深不想再改代码了。
    没有意外的话，除了api变更导致不能录制的修复，不会有更多变动。