Sleazy Fork is available in English.
JAVBUS自动显示预告片
< Σχολιασμός για τον κώδικα JAVBUS影片预告
感谢反馈与支持。你反馈的问题确实是存在的,现有的静态规则无法完全处理,这个番号规则生成比较复杂。 之前我与另外一个脚本的作者合作写了一个更全规则的版本,最近比较忙还没来得及测试发布。 目前静态规则处理失效后会调用在线查询的方法去匹配,缺点是有点慢。
推荐个思路:在每次获取到正确预览地址后,保存数据(番号和预览地址)到脚本数据里,已有下次可直接调用,没有的再次匹配成功到地址后写入。
就像楼主@qxin i写的根据番号搜索脚本一样,现在不是有avInfo数据表,可以加个预览地址数据表,用来保存番号和获取的正确预览地址,
后期数据存储多了,可以写成远程JSON用来调用。(可以参考自动无缝翻页的形式,有远程数据和本地获取的数据互补)
前期用脚本来匹配到正确地址,后期就收获地址,不断壮大这个数据库,也省去了番号预览地址规则匹配时间。
因为DMM预览地址太变态,有些系列,光规则就四五条,你再去匹配(mhb_w.mp4=3000 kbps\dmb_w.mp4=1500 kbps\dm_w.mp4=1000 kbps\sm_w.mp4=300 kbps\sm_s.mp4\dmb_s.mp4\vrlite.mp4等)这些后缀,又有很多条,大大延长了加载时间,这还不说无码系列的。
推荐个思路:在每次获取到正确预览地址后,保存数据(番号和预览地址)到脚本数据里,已有下次可直接调用,没有的再次匹配成功到地址后写入。
就像楼主@qxin i写的根据番号搜索脚本一样,现在不是有avInfo数据表,可以加个预览地址数据表,用来保存番号和获取的正确预览地址,
后期数据存储多了,可以写成远程JSON用来调用。(可以参考自动无缝翻页的形式,有远程数据和本地获取的数据互补)
前期用脚本来匹配到正确地址,后期就收获地址,不断壮大这个数据库,也省去了番号预览地址规则匹配时间。
因为DMM预览地址太变态,有些系列,光规则就四五条,你再去匹配(mhb_w.mp4=3000 kbps\dmb_w.mp4=1500 kbps\dm_w.mp4=1000 kbps\sm_w.mp4=300 kbps\sm_s.mp4\dmb_s.mp4\vrlite.mp4等)这些后缀,又有很多条,大大延长了加载时间,这还不说无码系列的。
其实 javspyl.tk 这个接口的后端就是按你说的方式来实现的。
这个接口的作者给我提供了他的数据库,我也写了一个初步的版本,但目前还没有时间来测试和优化,所以没有发布出来,请多包涵。
感谢支持与建议。
感谢你的脚本, 我写了一个脚本, 引用了你脚本很多代码, 在此感谢。
在使用中, 发现了很多不匹配的, 例如下面这些, 代码应该是正确的, 最起码在某个番号中是正确的
一些不成熟的建议:
00
就能获取到视频, 可以在第一次失败后, 再尝试一次, 能提高一些成功率, 可以将失败率降低 1/3 左右。00
, 而视频地址中却没有, 再结合第一点建议, 基本能通杀。 上方反馈的那些番号就是这样得到的。目前有个别番号比较特殊
doks
对应h_139doks
和36doks00
bf
后面添加了1个0, 然后在数字前面又添加了1个0 。thnib
这个番号在前面添加了n_1445
之后, 又把番号截断了1位添加的, 变成了n_1445thni
, 少了最后的b
感觉可以写成下面这种, 不分开, 直接写在一起。本身脚本内的代码最终也是把它们合在一起。
还有一种更特殊的
例如
keed-078
, 前面加了h_086
, 后面数字删0 视频地址https:///cc3001.dmm.co.jp/litevideo/freepv/h/h_0/h_086keed78/h_086keed78_sm_w.mp4
但是
keed-077
, 就是正常的 视频地址https://cc3001.dmm.co.jp/litevideo/freepv/h/h_0/h_086keed00077/h_086keed00077_dmb_w.mp4