版本：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 把上报推迟到切歌或播放结束，正好能拿到最终时长）。
版本：SPlayer Next v1.1.0（Windows 11 x64，安装版），已登录网易云账号，开着「启用听歌打卡」。
现象：「NCM 听歌打卡方式」选「NCBL 加密接口」（也是新装时的缺省值）时，在 SPlayer 里听的歌不进网易云的听歌排行；改成「原版日志接口」以后马上能进。
测试（同一个账号，在网易云手机客户端里看这首歌在听歌排行里的次数）：
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 把上报推迟到切歌或播放结束，正好能拿到最终时长）。