reF1nd

更新卡池角色名乱序的问题

1

HoshinoBot对角色名的顺序是有规定的，例如第一个是台服官译名，第二个是日文原名，第三是罗马音，第四是国服官译名，昵称则往后面排，虽然实际上不太可能严格按照这个顺序排列，但也至少应该保证台服官译排在第一个，否则使用机器人相关功能。例如兰德索尔花名册，会导致查询某个角色结果出来的是昵称。 但是用此插件的更新卡池更新出来的角色名是乱序的。 从[数据来源](https://api.redive.lolikon.icu/gacha/unitdata.py)来看，排在第二个的是台服官译名。如果在载入的时候能做到先载入第二个字段，然后剩下的按顺序载入就好了。

sing-box作为tuic客户端时，和mihomo(clash-meta)服务器端配合则无法代理quic

6

### 操作系统 Linux ### 系统版本 Ubuntu 22.04 ### 安装类型 sing-box 原始命令行程序 ### 如果您使用图形客户端程序，请提供该程序版本。 _No response_ ### 版本 ```shell sing-box version 1.8.0 Environment: go1.21.5 linux/amd64 Tags: with_gvisor,with_quic,with_dhcp,with_wireguard,with_ech,with_utls,with_reality_server,with_acme,with_clash_api Revision: 11bec79a06268f00e7c5a7d5509245855d6dd522 CGO: disabled...

上传文件夹报错

1

使用`-recursive`参数上传文件夹时，报错： ``` 2023/08/09 02:08:03 上传文件夹 /root/GD 出现错误：createDir() error: postFormJSON() error: cannot parse JSON: cannot parse number: unexpected char: "

HyperOS下，应用在后台一段时间后就无法接收通知了

8

先说现象：已停止的应用可以被fcmfix唤醒并接收通知，但是唤醒之后如果在后台经过一段时间，APP便无法收到通知了，但是APP的状态还是为**正在运行**（通过FCM Diagnostics可以看出fcm这边还是收到了通知，但是提示`No response to broadcast from xxxx`）。如果我手动把APP结束运行，那么下次来通知的时候APP又能被fcmfix唤醒并接收通知了。 推测是HyperOS millet墓碑机制改动，APP在后台一段时间后，状态虽然为**正在运行**，但实际上已经被墓碑了，没有后台活动了，通知也接收不到，目前只能通过将省电策略从智能限制改为无限制才能解决被墓碑的问题。但是别的模块例如MIUIGMS的做法又太暴力，MIUIGMS的做法是为所有勾选的应用保留后台，相当于这些应用一旦被唤醒就始终保持在后台运行，这样会带来极高的耗电。 如果目前的fcmfix能做到唤醒的时候将APP从墓碑中拉出来（例如模拟在前台打开此APP），这样应该可以正常接收通知了。