Closed elmagnificogi closed 1 year ago
你发的日志没有异常啊 有卡住阶段的日志吗?以及不用typora手动到picgo上传正常吗
是的 日志看不出来,之前发生这个情况的我也看过日志,都是没明显问题,就是单纯卡住了 9.28分开始就是第一次上传 后面的这个上传成功,已经是我用任务管理器结束任务了,然后typora自动重试的上传
手动上传我要后续试一下,明天或者后天吧
抓到了一次大量报错,下面错误重复了n次,log文件都有几m大小了
2023-04-07 18:25:23 [PicGo ERROR]
------Error Stack Begin------
Error: EPIPE: broken pipe, write
at Socket._write (node:internal/net:55:25)
at writeOrBuffer (node:internal/streams/writable:389:12)
at _write (node:internal/streams/writable:330:10)
at Socket.Writable.write (node:internal/streams/writable:334:10)
at console.value (node:internal/console/constructor:289:16)
at console.log (node:internal/console/constructor:363:26)
at consoleCall (<anonymous>)
at C:\Users\elmag\OneDrive\tools\Picgo\resources\app.asar\background.js:2:598472
at w (C:\Users\elmag\OneDrive\tools\Picgo\resources\app.asar\background.js:2:598634)
at process.<anonymous> (C:\Users\elmag\OneDrive\tools\Picgo\resources\app.asar\background.js:2:598683)
-------Error Stack End-------
2023-04-07 18:25:23 [PicGo ERROR]
------Error Stack Begin------
Error: EPIPE: broken pipe, write
at Socket._write (node:internal/net:55:25)
at writeOrBuffer (node:internal/streams/writable:389:12)
at _write (node:internal/streams/writable:330:10)
at Socket.Writable.write (node:internal/streams/writable:334:10)
at console.value (node:internal/console/constructor:289:16)
at console.log (node:internal/console/constructor:363:26)
at consoleCall (<anonymous>)
at C:\Users\elmag\OneDrive\tools\Picgo\resources\app.asar\background.js:2:598472
at w (C:\Users\elmag\OneDrive\tools\Picgo\resources\app.asar\background.js:2:598634)
at process.<anonymous> (C:\Users\elmag\OneDrive\tools\Picgo\resources\app.asar\background.js:2:598683)
由于log文件过大(他会自动删了重建),第一时间报错,那个好像被自动冲没了?不知道这个能不能帮到
是写日志文件的时候报错了,然后报错的时候又触发写日志的行为就死循环了
另外想问一下,你这个日志文件,是 picgo.log ,还是 picgo-gui-local.log ?
大致找到根源了,下个 beta 版本应该能修复
是picgo.log,~不过还有一种可能,我把picgo扔在OneDrive中,可能每次涉及同步的时候,又遇到了写log 可能会出错~
~我目前把picgo放到本地盘里,好几天了好像都没出错,似乎是这个问题?~
~但是我以前也是放onedrive的,都放了五六年了~
放到本地盘里,关闭log,依然会出现卡上传现象
我也遇到了一一样的问题,有帖子说Picgo设置中打开”使用内置剪贴板上传“后可以解决问题,但我的还是没有用。
大致找到根源了,下个 beta 版本应该能修复
在2.3.1版本中,除了内存资源占用导致卡上传之外,快捷键的quick_upload功能也无法使用,更新至beta6后问题解决。但是好奇作者大大为什么没有把这个作为bug fix提出来
前置阅读 | Pre-reading
PicGo的版本 | PicGo Version
v2.3.1
系统信息 | System Information
Windows
问题重现 | Bug reproduce
第一天打开picgo,并且使用正常,电脑休眠 第二天电脑唤醒,然后被远程连接 windows rdp,并没有使用picgo 又休眠 第三天唤醒后,第一次使用picgo,100%卡住。 具体体现是cpu占用大概20-40%的样子,长时间不会降低,手动结束任务后,typora会触发重新上传吧,后续上传就正常了
picgo都是被typora调用的,picgo app,exe的方式
这种卡住自从更新2.3.1就开始出现了,目前已经遇到了不下5次,流程可能和上面的略有不同,但基本都是第二天第一次使用卡住
图床是我自己的,配合的插件是
自定义Web图床
ZQian的1.1.1版本相关日志 | Logs
2023-04-07 09:28:29 [PicGo INFO] [PicGo Server] get the request {"list":["C:\Users\我的用户名称\AppData\Roaming\Typora\typora-user-images\image-20230407092829623.png"]} 2023-04-07 09:28:29 [PicGo INFO] [PicGo Server] upload files in list 2023-04-07 09:28:29 [PicGo INFO] Before transform 2023-04-07 09:28:29 [PicGo INFO] Transforming... Current transformer is [path] 2023-04-07 09:31:01 [PicGo INFO] [PicGo Server] is listening at 36677 2023-04-07 09:31:05 [PicGo INFO] [PicGo Server] get the request {"list":["C:\Users\我的用户名称\AppData\Roaming\Typora\typora-user-images\image-20230407092829623.png"]} 2023-04-07 09:31:05 [PicGo INFO] [PicGo Server] upload files in list 2023-04-07 09:31:05 [PicGo INFO] Before transform 2023-04-07 09:31:05 [PicGo INFO] Transforming... Current transformer is [path] 2023-04-07 09:31:05 [PicGo INFO] Before upload 2023-04-07 09:31:05 [PicGo INFO] beforeUploadPlugins: renameFn running 2023-04-07 09:31:05 [PicGo INFO] Uploading... Current uploader is [web-uploader] 2023-04-07 09:31:05 [PicGo SUCCESS] https://我的图床/static/upload/xxxx/202304070931199.png 2023-04-07 09:31:05 [PicGo INFO] [PicGo Server] upload result https://我的图床/static/upload/xxxx/202304070931199.png