Noahlias

> too bad. sry i need some more testing in this case. pushed something to the same branch again with terminal test outputs. > > commit [Akemi@852056b](https://github.com/Akemi/mpv/commit/852056b582099fcef195ab9008926828e9d82a45) file [Akemi/mpv@`852056b`/osdep/macos/remote_command_center.swift](https://github.com/Akemi/mpv/blob/852056b582099fcef195ab9008926828e9d82a45/osdep/macos/remote_command_center.swift) patch...

> Reference in new issue Yeah, the `mpv --no-config` does not reduce the bus error but plays video bus error.  ```bash (lldb) target create "./build/mpv" Current executable set to...

> Akemi/mpv@`9c8cbe7`/osdep/macos/remote_command_center.swift terminal output:  ```bash mpv on  tags/v0.37.0 [!?] via 🅒 base λ lldb (lldb) target create './build/mpv' Current executable set to '/Users/alias/Downloads/m/Misc/projects/mpv/build/mpv' (arm64). (lldb) run update_math.mp4 --no-config...

> tbh i have no idea what else could be done for now. though it might be worth gathering some more data. > > if you have rosetta installed, do...

> > i am using xcode 15.0.1 with the previous available SDK 14.0 and swift 5.9. i think it might be worthwhile to try this older version of xcode to...

> you can now find nightly builds from our master branch in our `Actions` section. there might be workflow runs with the same name from master (comment, build, etc), only...

原因我发现了是`bilireq`的一个grpc api请求问题 https://github.com/SK-415/HarukaBot/blob/6d454570fea335d4d0ffa7cf23f68cc178578ef2/haruka_bot/plugins/pusher/dynamic_pusher.py#L38-L44 具体就是装饰器里面都会携带metadata 恰好这个请求不需要metadata 如果携带就会-352错误,下面是最小化的demo,如果用之前的就是获取到了-352 ```python import grpc from google.protobuf.json_format import MessageToDict from bilireq.grpc.protos.bilibili.app.dynamic.v2 import dynamic_pb2_grpc, dynamic_pb2 from bilireq.grpc.utils.metadata import make_metadata def main(): channel = grpc.secure_channel( "grpc.biliapi.net", grpc.ssl_channel_credentials(), )...

应该是这个接口有限流操作 刚才那个只是临时解决 发现部署在服务器上 超过一定的请求就会这样 经过测试 加大`HARUKA_DYNAMIC_INTERVAL`的时间以及修改之前的metadata入参可以避免反复写日志 应该是同一个时间段不能多次请求这个接口

> > 应该是这个接口有限流操作 刚才那个只是临时解决 发现部署在服务器上 超过一定的请求就会这样 > > 经过测试 加大`HARUKA_DYNAMIC_INTERVAL`的时间以及修改之前的metadata入参可以避免反复写日志 应该是同一个时间段不能多次请求这个接口 > > 写-352日志的间隔时间=HARUKA_DYNAMIC_INTERVAL设置的时间 如果只加大HARUKA_DYNAMIC_INTERVAL（我设置成60）也无法避免-352且无法正常推送动态。只是让它变成了60秒报错一次而已 如果同时修改，仍然无法正常推送动态，只是后台不报错了。（我连续发了四条动态一条也没推送） 静待下一步解决策略（ 他用了一个很奇怪的设计,就是他的最近一条动态信息是保存在内存的不是持久化的在`sqlite`中的 也就是当你初次启动的时候它需要几次同步来加载你最近一次的最新动态信息(这个取决于你关注的人个数 也就是你需要等它将你的记录到内存中之后再发动态才会触发下面这段 大概就是等待你的HARUKA_DYNAMIC_INTERVAL*(你的关注人数+1)初始化好了， 之后就是你发完新动态之后等待HARUKA_DYNAMIC_INTERVAL*(你的关注人数) 它就会提示到新动态了 (说实话，这个动态爬取竟然不是一起爬的 而是每次执行``` uid = await db.next_uid("dynamic")``` 遍历的很奇怪)