支持分P视频

[by123456by]

P1标记的内容在P2被错误跳过

[hanydd]

确实是这样，本来以为b站想逐渐淘汰分p视频，就没做适配😌现在第一优先做这个功能

[zjns]

确实是这样，本来以为b站想逐渐淘汰分p视频，就没做适配😌现在第一优先做这个功能

考虑视频cid作为键，如果能获取到的话

Edit: b站现在合集里都加入分P支持了，应该是不会淘汰分P视频的

[by123456by]

确实是这样，本来以为b站想逐渐淘汰分p视频，就没做适配😌现在第一优先做这个功能

考虑视频cid作为键，如果能获取到的话

那样是不是会导致现在的数据失效，用现在的键+P几好些吧

[zjns]

也可以啊，一开始就用cid作为键是最好的，现在嘛，为了兼容，可能bv号+分P序号比较合适了

[hanydd]

考虑视频cid作为键，如果能获取到的话

Edit: b站现在合集里都加入分P支持了，应该是不会淘汰分P视频的

啊现在分p视频都能加进合集里啦？前几年阿B对分p视频下狠手，我做插件的时候都忘记还有这回事了😂 趁着现在视频不多，马上全部迁移到cid

[zjns]

考虑视频cid作为键，如果能获取到的话 Edit: b站现在合集里都加入分P支持了，应该是不会淘汰分P视频的

啊现在分p视频都能加进合集里啦？前几年阿B对分p视频下狠手，我做插件的时候都忘记还有这回事了😂 趁着现在视频不多，马上全部迁移到cid

这个视频可以测试合集分 p，目前还在灰度，但网页版应该大家都能看到 https://www.bilibili.com/video/BV1fE4m197Zy

[zjns]

可以 cid 作为键，提交的时候 bv 号可以作为补充信息，方便检索查看

[by123456by]

考虑视频cid作为键，如果能获取到的话 Edit: b站现在合集里都加入分P支持了，应该是不会淘汰分P视频的

啊现在分p视频都能加进合集里啦？前几年阿B对分p视频下狠手，我做插件的时候都忘记还有这回事了😂 趁着现在视频不多，马上全部迁移到cid

我建议是 bv号 分p号 cid 都传，然后在后端做处理，我记得好像哪里获取不到cid，但是我现在想不去来了

[zjns]

计划什么时候迁移呢，如果还早的话，我就先发个支持 sponsorblock 的 revanced App 版本了，revanced 这边支持 cid 很简单，目前还是用的 bv 号

[hanydd]

计划什么时候迁移呢，如果还早的话，我就先发个支持 sponsorblock 的 revanced App 版本了，revanced 这边支持 cid 很简单，目前还是用的 bv 号

可以，我更新api也会保证向上兼容的，应该只是会多加字段 （目前API文档正在施工中https://github.com/hanydd/BilibiliSponsorBlock/wiki ）

[zjns]

如果是新加字段的话，可以先确定参数名称吗，这样后面就不需要再发版了

[hanydd]

就叫cid吧，传纯数字（但是类型是string）。用哈希获取片段的接口的匹配可能会有点问题，因为如果要用BVID的哈希查询片段的话，没办法把cid的信息带进去，应该要在返回的片段object里加cid字段做匹配。

[{  // 视频对象
   videoID: string,  // BVID
   segments: [{      // 片段对象
       cid: string,  // <---------- 这种
       segment: float[],       // 起始和结束时间（秒），例如 [0, 15.23]
       UUID: string,           // 片段UUID
       category: string,       // 片段类别
       actionType: string,     // 片段动作类型
       locked: int,            // 该提交是否锁定
       votes: int,             // 该片段的投票数
       videoDuration: int,     // 提交时的视频时长，用于判断提交是否过期，未知时为 0，要求误差在 ±2 秒内
   }]
}]

如果不传cid的话就默认是p1

[zjns]

返回的数据结构也变了？又套一层array?

[zjns]

哦 是指 sha256HashPrefix 这个接口返回的数据每个片段会加上cid参数嘛，skipSegments 接口返回的数据结构不会变嘛

[hanydd]

哦 是指 sha256HashPrefix 这个接口返回的数据每个片段会加上cid参数嘛，skipSegments 接口返回的数据结构不会变嘛

所有的都加吧，这样保证都能和之前的接口兼容。

sha256HashPrefix 入参不改动，返回里面加cid，返回全部cid的片段；skipSegments入参加cid，返回也加cid，如果入参不传cid就查询全部cid的片段。提交片段的时候入参也加入cid，如果不传就默认P1。

这样子行不行

[zjns]

这样子行不行

加字段没问题，我还以为改了数据结构，APP目前只用到了skipSegments和viewedVideoSponsorTime这两个接口，其他接口由于对应的功能做起来麻烦就没用到

[hanydd]

加字段没问题，我还以为改了数据结构，APP目前只用到了skipSegments和viewedVideoSponsorTime这两个接口，其他接口由于对应的功能做起来麻烦就没用到

👌我之后更新都尽量保持兼容，避免还要频繁适配

[zjns]

👌我之后更新都尽量保持兼容，避免还要频繁适配

幸苦了，能提供服务器给大家免费用，现在这环境真的难能可贵，感谢！🙏 等以后用户多了后，如果有人能mirror就更好了，缓解服务器压力。

[hanydd]

幸苦了，能提供服务器给大家免费用，现在这环境真的难能可贵，感谢！🙏 等以后用户多了后，如果有人能mirror就更好了，缓解服务器压力。

一点微小的工作（）用的人越多越有意义。如果能在使用到的地方给个网站链接就好了🙏

[zjns]

没问题，必须加个跳转链接到本项目

[cxw620]

👌我之后更新都尽量保持兼容，避免还要频繁适配

幸苦了，能提供服务器给大家免费用，现在这环境真的难能可贵，感谢！🙏 等以后用户多了后，如果有人能mirror就更好了，缓解服务器压力。

需要 mirror 分流的话我来帮忙. 不过这个应该并发数不高吧, 热门视频有缓存百来个并发应该没问题. 所以应该蛮长一段时间作者的服务器应该都够用(主要是分流还是得从作者服务器拉数据而且由延迟, 总不能数据库层面同步吧, 或者作者加上同步专用的接口).