Open zhiqin14 opened 3 months ago
似乎在启动过一次隧道 a 后就可以正常地跟随程序启动,但启动过隧道 b 后再次打开程序又会启动隧道 b
等会测试一下,感谢反馈
这边没成功复现,方便的话可以上传录屏吗
试试更新运行库 https://docs-nyalcf.1l1.icu/gui/chang-jian-gu-zhang-chu-li#windows
仍然未能复现,测试使用开发版与最新发行版
还是不行x 目前用的是v0.2.0+2,dev分支要自己build吗
dev构建在Actions里有自动构建,如果不行建议先清除数据文件夹试试
dev一样,明天清数据文件夹试试 (你dev认为releases里面的才是最新的x
qwq 数据是存在 %appdata%\moe.xmcn.nyanana 里吗 (dev版程序结束的速度貌似有点过慢了 ;w;
qwq 数据是存在 %appdata%\moe.xmcn.nyanana 里吗 (dev版程序结束的速度貌似有点过慢了 ;w;
是的
Upstream bug 具体成因尚不清楚
情况相同
(在解压完frpc后似乎并不会马上检查frpc是否存在
暂时没有什么思路,Issue 先开着
确实有此问题,本人已在Windows 11 Canary 27686上使用0.2.1(+1)复现出来了(
Issue 175出现条件(本人测试得到): 1.两个节点均为新建(即启动程序时不存在,在刷新后存在) 2.在此情况下设置A随软件启动 3.先打开A节点,再打开B节点 4.关闭程序重启软件,查看控制台发现所属IP为B节点
当然,这只是我复现时的情况,并不保证其他操作流程不会出现此情况
我是23h2 (22631.4037) www
发件人: Suisuroru @.> 发送时间: 2024年8月24日 19:31 收件人: Muska-Ami/NyaLCF @.> 抄送: zhiqin__ @.>; Author @.> 主题: Re: [Muska-Ami/NyaLCF] [BUG]: 无法正确启动跟随程序启动的隧道 (Issue #175)
确实有此问题,本人已在Windows 11 Canary 27686上使用0.2.1(+1)复现出来了(
― Reply to this email directly, view it on GitHubhttps://github.com/Muska-Ami/NyaLCF/issues/175#issuecomment-2308361698, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ARHPQPCPS5SDJHT5SRIA363ZTBVHTAVCNFSM6AAAAABMWMW3OSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGM3DCNRZHA. You are receiving this because you authored the thread.Message ID: @.***>
@Suisuroru 有空我会重新检查一次逻辑,理论上是不应该的
疑似参数保存问题? 首次修改重启后直接查看frpc文件目录下的配置文件为B节点,而非应当被启动的A节点 而且此情况只会出现一次,第二次启动就会恢复正常
------------------ 原始邮件 ------------------ 发件人: "Muska-Ami/NyaLCF" @.>; 发送时间: 2024年8月25日(星期天) 上午6:42 @.>; @.**@.>; 主题: Re: [Muska-Ami/NyaLCF] [BUG]: 无法正确启动跟随程序启动的隧道 (Issue #175)
@Suisuroru 有空我会重新检查一次逻辑,理论上是不应该的
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
疑似参数保存问题? 首次修改重启后直接查看frpc文件目录下的配置文件为B节点,而非应当被启动的A节点 而且此情况只会出现一次,第二次启动就会恢复正常 … ------------------ 原始邮件 ------------------ 发件人: "Muska-Ami/NyaLCF" @.>; 发送时间: 2024年8月25日(星期天) 上午6:42 @.>; @.**@.>; 主题: Re: [Muska-Ami/NyaLCF] [BUG]: 无法正确启动跟随程序启动的隧道 (Issue #175) @Suisuroru 有空我会重新检查一次逻辑,理论上是不应该的 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>
关于这个情况的日志,可以参考我提交在 #179 上的日志,在分析日志时发现了 #179 的问题
我重新检查了相关的代码,认为逻辑上是没有问题的 这应该是一个状态管理系统的 BUG,可能由 GetX 或 Flutter 本身代码 导致,应向上游依赖反馈
尝试最新版本启动器是否能解决这个问题,修改了一下逻辑 不确定是否还会触发
还是不行的x
问前检查
问题描述&复现过程
假设有 a, b 两条隧道,a 的创建时间早于 b 在未创建隧道 b 时为隧道 a 勾选跟随程序启动后,再创建隧道 b ,再次打开软件控制台输出隧道 b 的启动信息而非隧道 a,且进程列表中的隧道 id 和日志中的(大概)为隧道 a 的id
版本
0.2.0 (+2)
运行日志