Predidit

这是 https://github.com/altstoreio/AltStore/issues/1034 我看到它链接到 https://github.com/RyanYuuki/AnymeX/pull/93 这一有效的解决方案 很明显，altstore 无法签名捆绑了未签名的 xcframework 的 ipa 。 这很明显是一个 altstore 或是 sidestore 实现中的一个错误。 上面的解决方案是使用过期的企业证书进行签名，就像 @louvyu 做的那样，我怀疑 @louvyu 在有些场合的失败是某些签名软件不会签名 xcframework 而只签名本体。 如果我们一定要修复这一问题，我们只能使用过期证书签名我们的 mpv.xcframework，或是使用过期证书签名 kazumi.ipa 的所有内容。 @ErBWs 你对此怎么看，我觉得使用过期证书存在合规风险，并且我担心这种被滥用的过期证书可能导致一些未预期的问题。

这三个包的大小差异非常大，很自然地想到 xcframework 符号链接相关问题。 可能不是 xcframework 未签名问题，不知道其他更加熟悉 macOS/iOS 的开发者怎么看。

@ErBWs 1.4.4 在之前的 Issue反馈中是可以侧载的，1.4.4 还在使用 fvp ，其对应的 xcframework 是有签名的，也就是 _CodeSign 话说你对 syncPlay 协议的实现有兴趣吗，我在延时补偿遇到了相当大的问题

@ErBWs 如果愿意使用自己的 Apple 开发者账号，我们可以上架 testflight 其实审核的问题比较大，我们应该很难通过审核

如果你的意思是根据 #925 中我的提议进行讨论 1. 我们现在的架构完全是根据 bangumi API 返回的番剧信息作为索引的，当通过片源站点进行检索时，我们的 bangumiItem 来自哪里，我们使用什么东西填充需要 bangumiItem 填充的地方 (例如 历史记录) 2. 我们不应该新增一条规则来抓取封面图片，因为这会有各种烦人的问题，例如损坏的图片，或是 referer 相关问题 还是说这个 Issue 只是一个提议，你倾向于完全由我们来实现相关功能？

我注意到最近的错误日志发生在 2025-04-04 17:27:43.765856 你的尝试发生在这个时间点之后吗

这看上去可能是缓存大小达到了 DIO 允许的上限，你尝试过删除一些记录吗

这里的缓存指的是历史记录，大概就是说可能是你的历史记录太长了导致同步出问题。 ZIP版本所有文件都是经过签名的，不可能被误报。MSIX版本只签名了安装包本体，没有签名内部文件，正常来说只要本体有签名，内部文件就会被豁免，我不知道为什么仍然发生了误报。 我会尝试在下个版本签名 MSIX 安装包内的所有文件。

Kazumi 使用跨平台框架 flutter 开发，这非常容易出现误报，因为安全厂商在提取使用这类框架开发的恶意软件时，可能错误地将框架部分的特征作为病毒特征。这会误伤大量使用该框架的程序。 这也是我们为什么要进行代码签名。

在 media_kit 的框架下很困难，因为 media_kit 的底层是 mpv ，而 mpv 本身不支持 thumbnail 并且没有支持计划。 我能想到的方法有两个，但是都不怎么优雅 1. 同时运行两个播放器，将第二个播放器的内容作为预览 2. 使用 ffmpeg 批量从源地址生成 thumbnail 并储存到缓存文件夹，这里有两个主要问题 a. 我们现在的 ffmepg 静态链接到 libmpv 库，需要修改相关编译脚本来实现动态链接，并为所有平台编写 FFI 胶水代码来实现 dart-native 互操作，这在...