关于开启断流重连

[Smecta]

问题描述：

开启后设置间隔0或者2000 ，发现init初始化返回的实例中player 然后使用player.onerror去监听报错，如果出现错误，则

player.onerror = (e) => {
   ....
  // 发现这里的代码只能执行一次，如果在这里执行了player.close() ，并不能去销毁，而会一直去重连操作
}

问题描述2:

如果不在onerror去销毁的话，能否给出一个设置阈值的参数？比如重连N次后，去停止重连并销毁，最好可以给一个回调，方便去处理关闭画面loading和销毁页面其他状态？

问题描述3:

如果卡住，重建视频 期间一旦出现 视频ERROR 这里也不会去执行player.onerror这个方法

[shady-xia]

感谢提出，我会考虑这里的优化

[Gyxy]

这个卡住重连应该是有问题的，如果是因为推流端断网重连导致流中断了一部分进而致使看播端卡主重连 这个会重复执行7-8次才能正常播放

[shady-xia]

这个卡住重连应该是有问题的，如果是因为推流端断网重连导致流中断了一部分进而致使看播端卡主重连 这个会重复执行7-8次才能正常播放

好的，收到

[Samuel0129]

各位大大，想请教一下卡住重建问题，现象是：

1. 直播追帧最开始如果卡住重建视频，可以成功显示出来，手动频繁rebuild也没有问题；
2. 过了五六个小时之后，会卡住重建，这时log仅显示[MSEController] > MediaSource onSourceOpen，后面相关[FLVDemuxer]等信息不再打印，直播不再播放，手动rebuild也没有用（图见楼上）；
3. 同一个页面多个video元素播放同一个直播流，其中一个卡死之后，手动rebuild所有播放器，其他的都可以正常显示出来；

希望大大们能给些意见，感谢！后学末进，如果是低级问题，还望见谅。。

[shady-xia]

关于“卡住重建的问题” 我感觉这个“卡住重建”貌似没什么太实际的作用，视频本身也是有重连的功能的，这块暂时没什么好的想法，大家有什么好的思路吗？

[Smecta]

目前确实没多大用处，我给默认关了，但是stuck的问题那里出现问题了，目前我也在摸索中，没有什么好的建议，我就从我目前的业务逻辑去思考的，可以看看我的需求痛点 业务逻辑大致是这样的:

1. 点击左侧的视频tree中的某个节点，右侧会添加相对应的视频示例去向后端拉流播放，左侧tree的选中节点激活对应的icon变化，比如没在播放的是灰色的，再播的是黄色的状态，并记录在播的list,以方便切换视频分屏样式，如图

2. 但是在拉流之前，前端需要请求一下后端的一个是否可播的接口，并返回相关的参数，用于拉流请求的url去拼接，比如一些appKey或者temp之类的params
3. 后端提供的是否可播的接口，返回能播的状态（分状态）： （1）播放前，实际视频本身去拉流会出现错误，这时候就需要player.onerror这个监听，如果出错，有可能是网络出错，业务就需要去重播，以避免网络导致的不能播放的问题，所以需要用到重播功能，但是如果一直重播，一直出错，那肯定不行，业务又提出在规定时间内，规定次数去进行重播，超过了就不要去重播了，给用户一个提示，告知视频播放失败。目前缺少这部分逻辑的处理，考虑上业务不同，所以希望能给一个回调函数。 （2）播放中，视频重建 卡住重建，就stuck的问题，目前的情况视频流如果一直稳定的情况下没有问题，但是一旦视频流出现问题，变成不可播的状态 ，网络错误还是媒体错误，都会导致这里的逻辑出现问题，所以希望结合播放前的处理，这里也放一个回调函数来自定义业务。

[shady-xia]

感谢回复，思路很清晰，目前初步的想法是：

1. 断流重连： 1）可能会增加一个 maxReconnectAttempts 参数用于控制重连次数 2）手动调 close() 后不再触发自动重连的逻辑 3）加一个断流重连的事件或者回调函数
2. 卡住重建： 考虑到目前卡住重建的解决方法不是很完善，这里打算暂时改成回调函数的方式，让使用者自定义处理逻辑

[shady-xia]

已发布v0.3.0，对于重连的问题加了参数和回调，具体见： https://github.com/shady-xia/flvExtend/releases/tag/v0.3.0

欢迎测试