Repository navigation
[Bug]: 听歌打卡选「NCBL 加密接口」时上报被服务端收下但听歌排行不计数，「原版日志接口」正常 #339
Description
版本：SPlayer Next v1.1.0（Windows 11 x64，安装版），已登录网易云账号，开着「启用听歌打卡」。
现象：「NCM 听歌打卡方式」选「NCBL 加密接口」（也是新装时的缺省值）时，在 SPlayer 里听的歌不进网易云的听歌排行；改成「原版日志接口」以后马上能进。
测试（同一个账号，在网易云手机客户端里看这首歌在听歌排行里的次数）：
| 打卡方式 | 做法 | 结果 |
|---|---|---|
| NCBL 加密接口 | 一首排行里已有记录的歌，从头完整放 3 遍 | 放之前 17 次，最后一遍放完约一小时后仍是 17 次 |
| 原版日志接口 | 切换后放另一首歌 | 放完以后排行里马上有了这一次 |
NCBL 那 3 遍，日志里只有 1 条失败：听歌打卡失败(scrobble_v1): Error: scrobble_v1: 请求异常: fetch failed，另外两遍没有失败记录。按 out/main/index.js 第 5200 行，成功的判据是回包 code === 200 且 data.successfiles 里有刚传的文件名，所以另外两遍是被服务端收下了、但没有计数。成功只打 debug，日志文件里看不到。
一个可能的原因（没有验证）：两种方式报的结束方式不一样。原版日志接口的 play 记录写 end: "playend"（out/main/index.js 第 4822 行）；NCBL 的 _pld 记录固定写 end: "interrupt"（第 4938 行），time、realtime 是上报那一刻已听的秒数（到 neteaseScrobbleThresholdMs 就报，即时长一半或 240 秒，第 3134 行）。也就是说 NCBL 每次报的都是「放到一半被打断」，服务端可能不算。其余字段与官方客户端有什么差别，我没有比对。
影响：新装的缺省模式是 ncbl（out/main/index.js 第 379 行 neteaseScrobbleMode: "ncbl"），用户打开听歌打卡以后用的就是这一种，界面上看不出没计数。
建议：缺省改成 legacy，或在设置里说明 NCBL 方式目前可能不计入排行；NCBL 这边可以试试 end 写 playend、time 用实际听的时长（#288 把上报推迟到切歌或播放结束，正好能拿到最终时长）。
Activity
github-actions commentedon Oct 1, 2026
👋 @nattwood913-web
感谢提交 Issue！我们已经收到您的反馈，会尽快确认您的问题。
Thanks for opening this issue! We have received your report and will review it as soon as possible.
nattwood913-web commentedon Oct 1, 2026
更正：上面的 NCBL 测试很可能被 #340 干扰了，结论先当作未确认。
后来发现单曲循环下打卡只报第一遍（#340）。回看本地
play_history，测试那首歌（时长 276 秒）只有前后紧挨的 2 条记录，中间没有别的歌：onTrackEnded(true)）时才开新的一条；列表循环下重新加载同一首歌，key 不变，不会多出一条。所以第二条只能是单曲循环的自动重播（另一种可能是中途切到别的歌、不到 5 秒又切回，MIN_RECORD_MS以下不记）。测试前上一首歌也是连着整首 6 条，单曲循环应当一直开着。照 #340 的代码路径，单曲循环自动重播那几遍都不会上报。第一条里那次到阈值的上报，就是日志里唯一那条
fetch failed；第一条多出来的 37 秒如果是在上报之后拖回开头，还可能再报一次（onPosition的jumpedBack会rearm）。所以 NCBL 真正成功送出的最多 1 次，也可能 0 次，不是我上面写的「另外两遍被服务端收下」。原版日志接口那边「马上能进」的是第一遍，与 #340 不冲突。NCBL 是否计数，要在列表循环下重测才能下结论；重测之前，上面「可能的原因」一节也只是猜测。
fix: 修复播放日志上报与单曲循环计时 (Refs #339, #340, PR #288)
github-actions commentedon Oct 24, 2026
🎉 @nattwood913-web
感谢您的反馈！该问题已修复，并将在当前开发版或下一个正式版中生效。
若您仍能复现该问题，欢迎重新提交新的 Issue。
Thanks for your report! This issue has been resolved and will be available in the current dev build or next stable release.
If you can still reproduce this problem, please open a new issue.