Greasy Fork is available in English.
自动追帧bilibili直播至设定的buffer length
< Rückmeldungen auf Bilibili直播自动追帧
“显示追帧”后似乎会增加兜底失败的可能性。把功能选项隐藏后似乎能一定程度缓解这个问题。
目前测试勉强共存的顺序如图。
是只有“阻止轮播”/“屏蔽视频轮播”功能受影响还是其他功能也会有影响？ 和其他插件的冲突可能简单也可能很复杂，问题不大的话我有空了再仔细看看
复现不稳定的原因不知道是否跟缓存有关。
隐藏后刷新，再显示后再刷新，依然能阻止一段时间的轮播。但是再过一段时间轮播下一个视频（BV）后就又失效了，需要先载入成功一次该轮播的视频，再次刷新后才能成功被bilibili直播净化阻止。而且当该视频（BV）轮播结束换下一个视频（BV）时就马上会失效播放起来了，甚至都不需要刷新，就跟开播那一下的效果是一样的。
目前如果所有脚本的界面都成功显示的话，除了轮播的问题之外其它功能似乎都能正常运作。
另外不知道是不是这个脚本追帧的实现方式有缺陷，我记得以前官方B站曾经在播放器上灰度测试过一段时间同样的变速追帧功能，并没有出现音画不同步的问题。
尝试了一些更改，更改之后的版本上传到GitHub上了，你可以试下
如果没什么别的问题的话会之后把这个版本发布到Greasy Fork，到时候可以再在Greasy Fork重新安装一次启用自动更新检查
轮播自己重新开始的情况我没遇到，你可以测试下这个版本还有没有
官方的播放器变速我没找到过，所以没法评价
（GH测试版）
现在开了这个脚本后似乎会导致直播间页面无法正常下播，会一直卡在最后的画面而不是显示下播后的推荐画面。不知道是否跟这次的改动有关？还是说自动减速的事？
至于冲突问题，我再测几天试试不同的组合……
不行，还是会跟净化冲突导致阻止失效，主要体现在分页（tab）被丢弃（discard）后重新载入的时候。
我猜会不会是跟原画相关的功能有关？毕竟那个功能听起来需要捕获并给播放器发送串流地址信息，会不会就把轮播的视频信息当成直播的又给整上，导致了这个问题。而且当重新载入被丢弃的分页时，浏览器会选择读取缓存，我怀疑这里也会造成脚本的一些问题。
看图，脚本没选阻止，但却也触发了脚本阻止的效果。明显是缓存的效果。（这可不是我后来取消勾选的……）
今天在直播间挂着挂着突然又开启轮播了……这个脚本有什么会一直更新状态的吗？难道是“自动刷新”的锅？
我这里复现不出你上面提到的轮播的问题，可以看下控制台有没有什么疑似相关的报错吗？
另外可以Windows沙盒/虚拟机里安装chrome浏览器、或者直接用百分浏览器的便携版这样自带独立环境的浏览器测试下吗
OBS推流需要主播端手动去进行下播才会切换至下播状态，断开推流不会自动下播。另外flv协议推流因为B站服务器问题，有概率会在主播断开推流/网络断开后，无限重复断开前最后几秒的内容。
bilibili直播净化会将 window.__NEPTUNE_IS_MY_WAIFU__ 设置为 {} 且只读，看了一下这个脚本会用到这个全局变量，导致菜单加载失败，我也是装了这个脚本没找到设置菜单，看了下代码才发现问题，原来的操作确实比较暴力，没有考虑的其他脚本的兼容性，我看看能不能换成更柔和的方式
发现两个冲突问题
首先，与bilibili直播净化冲突
当上述脚本的优先级比这个脚本要高时：
开启上述脚本的“屏蔽视频轮播”功能会导致这个脚本无法正常载入。
上述脚本关闭该功能后，这个脚本载入正常，且轮播屏蔽功能正常。但会导致上述脚本界面载入缓慢。
而当这个脚本的优先级比上述脚本要高时：
会导致上述脚本界面载入缓慢。
接着是与Bilibili Live Tasks Helper冲突
当两个脚本一起用时，无论先后顺序如何：
都会导致“阻止轮播”功能失效。
但可以用bilibili直播净化兜底阻止轮播。（由于两个阻止脚本阻止后画面显示的提示语不同，所以能确定是谁阻止成功的。）不过偶尔会出现阻止失败的情况。