youpaishidifu
d8c0e62a2d
修复跨平台答案混用: 表格优先策略必须检查heading语义相关性
...
- 表格优先策略: 不再盲目优先含'操作'的表格, 只优先heading与查询有交集的表格
- 表格兜底策略: 同上, 只兜底与查询语义相关的操作/支持表格
- 表格内容奖励: 同上, 3.0x加权只给与查询相关的表格
- 根因: '操作方式'表(交互模式)含'操作'被盲目优先, 覆盖了'权限级别'表
- 测试: '权限级别'→权限级别表格(20.51), '操作方式'→操作方式表格(49.54)
2026-08-05 15:01:00 +08:00
youpaishidifu
49a95fb808
修复commit charge阈值判断和OCR乱码字符检测
2026-08-05 14:47:44 +08:00
youpaishidifu
cd2e1f5e36
fix: .gitignore 补全无下划线前缀的调试/测试脚本规则 - 曾有 debug_kb.py/test_kb.py 因命名绕过 _debug_*/_test_* 规则待被误入库
2026-08-05 14:30:50 +08:00
youpaishidifu
a181c18c79
移除不应入库的文件:数据库、调试脚本、测试脚本;更新.gitignore
2026-08-05 13:36:57 +08:00
youpaishidifu
4d7017be6a
修复知识库搜索:表格内容不再被切分,表格section优先返回
...
- knowledge_base.py: _split_body_by_list_items检测表格区域,不切分表格行
- knowledge_base.py: 添加独立表格section,确保表格内容可被搜索匹配
- knowledge_base.py: 表格兜底策略:最佳文档含操作/支持表格时强制加入并置顶
- knowledge_base.py: reranking后无条件优先返回含操作/支持的表格section
- .gitignore: 添加msg_history.db和诊断脚本到忽略列表
2026-08-05 13:22:27 +08:00
youpaishidifu
271ea21489
fix: 偏旁过滤失效 - Unicode列改为真实码点+常用字同形写-防误杀 (windowmsgbot)
2026-08-05 10:43:26 +08:00
youpaishidifu
3bae125392
修复漏消息:gate整块丢弃+行合并黏时间戳+stage尾部连坐 (windowmsgbot)
...
- 新增 _block_has_cjk_message:整屏时间戳全过期但含中文消息内容时放行给下游去重
- gate 两个全过期分支改为含中文消息内容即放行,不再整块丢弃连坐新消息
- stage splitting 中段/尾部不再按继承旧时间戳丢弃,仅>2h且非新鲜才丢远古历史
- 行合并增加 _TS_START 正则,禁止独立时间戳行被黏进消息
- 新增 _normalize_timestamps 规整 OCR 逐字空格/全角冒号时间戳,修复孤儿空格导致漏消息
- 内存泄漏修复保持不动(锁超时/句柄释放/启动失败计数/双重内存预检/看门狗)
2026-08-04 21:31:35 +08:00
youpaishidifu
7d3c73a3bf
fix: OCR噪声检测 - 用户消息与bot回复相似度≥90%时跳过
...
问题:OCR把bot回复内容误识别为用户消息,导致重复回复
根因:EasyOCR读取屏幕时,把右侧bot回复区域的文本也读取为用户消息
修复:
- 新增_last_bot_reply_content变量存储最近bot回复内容
- record_bot_reply方法更新该变量
- 消息处理前检查相似度,≥90%则跳过
- 添加SequenceMatcher导入
2026-08-04 15:44:25 +08:00
youpaishidifu
7e6d105b73
fix: EasyOCR超时也计入连续失败计数 - 防止超时跳过绕过杀进程逻辑
...
问题:连续3次EasyOCR超时未触发杀进程,因为'超时跳过'日志未增加失败计数器
根因:只在_q.get()返回None时增加计数器,线程超时is_alive()检查未增加计数器
修复:EasyOCR线程超时时也增加_easyocr_consecutive_failures,达到阈值触发杀进程
2026-08-04 15:27:06 +08:00
youpaishidifu
33848de623
fix: 修复cleaned_item未定义错误 - 调整清理顺序
...
问题:QQ轮询时cleaned_item变量未定义
根因:OCR清理函数调用顺序错误,在使用变量后才定义变量
修复:将cleaned_item = self._clean_ocr_prefix(item)移到使用前
2026-08-04 15:14:40 +08:00
youpaishidifu
597ed7d2fd
fix: 微信窗口被覆盖时无法唤醒 - 保留PID快速EnumWindows + 冷却缩短到10s
...
问题根因:
1. UIA (auto.WindowControl) 在窗口被其他程序覆盖时搜索不稳定
2. 缓存HWND验证失败时,PID也被清空,导致每次都要从psutil全进程扫描重新找PID
3. 搜索失败后30s冷却太长
修复:
- 仅清HWND,保留PID供后续EnumWindows快速复用(毫秒级,跳过psutil扫描)
- 新增PID快速路径:验证失败后先用缓存PID直接EnumWindows,再走UIA和psutil兜底
- 冷却时间从30s缩短到10s,加快恢复轮询
2026-08-04 14:03:19 +08:00
youpaishidifu
a3b0e35581
fix: EasyOCR内存不足时强制CPU模式,避免CUDA加载导致系统冻结
...
- monitor.py: 内存阈值从2GB提高到3GB,CUDA加载torch需要大量内存
- easyocr_worker.py: 新增物理内存预检(3GB阈值),不足时强制CPU模式
- easyocr_worker.py: _init_reader()再次检查物理内存,双重保障
- 改进错误日志:记录内存详细信息(总量、使用率)
- 解决:内存不足时仍加载CUDA导致电脑冻结的问题
2026-08-04 12:18:54 +08:00
youpaishidifu
7d8d39f7b6
fix: 修复OCR日期提取错误导致时间戳误判为未来的问题
...
- OCR常把日期和时间连在一起:2026/8/319:45:20 → 匹配到2026/8/31(未来/非法)
- 改进日期解析:从d向下截断,找到第一个合法且≤今天的日期
- 处理:2026/8/31(未来8月31日)→ 2026/8/3(过去8月3日)
- 处理:2026/8/32(非法日期)→ 2026/8/3(过去8月3日)
- 这样has_past_date=True,时间戳19:44/21:13等不会被误判为未来时间
2026-08-04 09:47:57 +08:00
youpaishidifu
161d2dd95b
修复基线抑制后截图 hash 导致消息被跳过的问题:
...
- 基线抑制时清除截图 hash(_last_screenshot_hash.pop)
- 防止下次轮询时 hash 相同直接跳过 OCR,导致消息永远等不到回复
- 更新注释:从'三项关键处置'改为'四项关键处置'
2026-08-03 23:07:01 +08:00
youpaishidifu
d6691f6037
修复 EasyOCR 连续启动失败不触发重启的问题:
...
- 新增 _easyocr_consecutive_startup_failures 计数器,跟踪子进程无法启动的次数
- 当连续3次启动失败时,清除冷却时间并重置状态,强制重试启动
- 前2次保留冷却(预留初始化时间),第3次强制清除冷却
- 在所有重置 _easyocr_consecutive_failures 的地方同步重置启动失败计数
- 解决 EasyOCR 全程未启动但从未触发杀进程重启的问题
2026-08-03 22:34:22 +08:00
youpaishidifu
795a245de7
修复两个bug:
...
1. 问题3:OCR逗号断行 - 在_process_ocr_output中添加连续行合并逻辑,防止EasyOCR将中文逗号视为行边界导致消息前半段丢失
2. 问题4:回复重试逻辑失效 - 为_paste_and_send添加force_retry参数,_execute_reply重试时跳过60秒冷却检查,实现真正的5秒间隔重试机制
2026-08-03 21:31:14 +08:00
youpaishidifu
d87e482e1e
修复微信端知识库答非所问 + QQ OCR 漏消息(双 bug 修复)
...
knowledge_base.py(问题2:微信端答非所问):
- 文档级标题语义匹配改为 token 级(原仅字面子串匹配),OCR 丢失"php"只剩"管理员端默认"也能正确命中 phpadmin
- 新增"管理员+默认"组合强偏好:无"领地"时 phpadmin ×3.0、protect ×0.4,避免退化查询误选 protect/全局配置
- section 级重排新增 bonus +30:查询含"管理员+默认"时,偏好正文真正含"密码/登录/ypshidifu"的 section,压过"## 目录"目录项
monitor.py(问题1 + 问题2 上游):
- 新增 _split_and_denoise_segments:按消息边界预分割 + 分段噪声隔离,修复 Windows OCR 大杂烩把用户消息当噪声整段丢弃(QQ 漏消息)
- 候选行剥离 bot 自身旧回复文本:OCR 把用户新提问与屏上 bot 旧回复拼成一行时,先剥离旧回复再走过滤,消除答非所问的上游拼接根因
测试:新增 debug_kb.py 复现退化查询、test_kb.py 回归;跨主题回归全部正确,py_compile 通过
2026-08-03 20:52:08 +08:00
youpaishidifu
8ed93382e0
修复两个bug:1. EasyOCR线程崩溃(_OCR_TIMEOUT未定义) 2. 知识库搜索优化(核心名词匹配奖励+文档标题语义匹配)
2026-08-03 18:17:43 +08:00
youpaishidifu
47996cd1b8
微信窗口验证修复:支持国内版weixin.exe进程名
2026-08-03 17:44:43 +08:00
youpaishidifu
f95a711c8c
搜索结果显示增强,展示更多匹配详情
2026-08-03 17:32:18 +08:00
youpaishidifu
c51a585bb9
微信窗口验证增强日志,诊断窗口无效原因
2026-08-03 17:32:04 +08:00
youpaishidifu
c3a210efef
知识库搜索优化:列表项二次切分,提升细粒度匹配精度
2026-08-03 17:31:45 +08:00
youpaishidifu
24036ecab9
fix: indentation error in _is_white_bubble_pixel decorator
2026-08-03 16:48:24 +08:00
youpaishidifu
c6c8cc0571
@
...
fix: 微信颜色检测放宽+KB精确匹配+自动回复重试
1. monitor.py - 微信白色气泡检测阈值放宽(>=245->>=240, >=3->>=2)
适配新版微信UI颜色变化,减少漏检
2. knowledge_base.py - 精确短语匹配(5x加分)+子串匹配(2.5x/1.5x)
防止查询被不相关文档抢走高分
3. gui.py - 自动回复发送失败重试(3次/5秒间隔)
连续失败退避本轮,避免反复抢焦点
4. .gitignore - 补充build目录下的证书/构建产物
@
2026-08-03 16:42:21 +08:00
youpaishidifu and WorkBuddy
708bcbf315
fix: 微信截图调试诊断 - 调试截图提前保存+PrintWindow失败回退
...
- 调试截图保存提前到所有检查之前(之前在size check之后,太小的图不保存)
- PrintWindow结果太小(<50px)时自动回退到屏幕截图
- 添加详细诊断日志(唤醒结果、可见性、前台状态、截图尺寸)
- QQ截图同样优化(PrintWindow太小回退+调试截图提前保存)
根因:微信PrintWindow返回None或空白图时,代码直接return[]不保存任何调试图片
导致用户看到截屏文件夹空白但日志说继续截图
Co-Authored-By: WorkBuddy <noreply@workbuddy.ai >
2026-08-03 16:13:23 +08:00
youpaishidifu
99e2a1cfe7
fix: 两个问题修复
...
1. QQ截图路径空值导致[Errno 2]错误 - 添加时间戳生成路径
2. 窗口被遮挡时使用PrintWindow API截取内容
- 新增_screenshot_window函数使用PrintWindow API
- QQ和微信截图逻辑:当窗口不在前台时尝试PrintWindow
- PrintWindow失败时回退到屏幕截图
2026-08-03 15:42:36 +08:00
youpaishidifu
2162a49068
fix: 昨天的时间戳不再被误判为今天未来的21:14
...
- 在_ocr_text_has_fresh_timestamp中提取日期信息(如2026/8/2)
- 如果日期是过去的(昨天或更早),跳过未来时间戳拦截
- 修改_is_timestamp_old函数,添加skip_future_check参数
- 解决问题:OCR文本包含2026/8/2 21:14:38,被误判为今天未来的21:14
2026-08-03 15:20:28 +08:00
youpaishidifu
b07fc75d99
@
...
fix: window activation bug - verify PID before using cached HWND
Root cause: _ensure_hwnd cached HWND without verifying the owning process.
When target app exits, OS reuses HWND value for another process, causing
activation of wrong window (e.g. browser/editor disguised as QQ/WeChat).
Changes:
- Add _validate_wechat_window() to verify process name == WeChat.exe
- _ensure_hwnd cache hit: verify HWND belongs to target process via PID
- TXGuiFoundation fallback: verify PID belongs to QQ.exe/TIM.exe
- _find_qq_window_fresh: same PID verification for TXGuiFoundation
- _ocr_read_wechat: validate window before OCR capture
- Raise min window size threshold from 200x100 to 300x200 everywhere
@
2026-08-03 14:47:23 +08:00
youpaishidifu
eb5a260534
build.bat: default skip cert+sign, fixed arg parsing for PowerShell
2026-08-03 12:48:39 +08:00
youpaishidifu
a9b853ec0a
sign.bat: replace all Chinese with pure ASCII to fix GBK encoding issue
2026-08-03 12:39:35 +08:00
youpaishidifu
1814f42d0e
build.bat: fix cmd variable expansion - PYINSTALLER var caused whole string to be treated as single command
2026-08-03 12:30:57 +08:00
youpaishidifu
00235dd0b6
build脚本GBK编码+参数解析修复(去除所有前缀后匹配)
2026-08-03 11:13:36 +08:00
youpaishidifu
686aae7e53
build.bat参数解析兼容PowerShell+gitignore修正保留构建脚本
2026-08-03 11:03:57 +08:00
youpaishidifu
fa67eb407e
@
...
修复3个问题:
1. EasyOCR OOM降级CPU+重启恢复重检内存:_init_easyocr和_ensure_easyocr_subprocess添加内存检测,<2GB强制CPU;start()添加full_restart参数,用户手动启用时重置OOM计数重新评估GPU/CPU
2. PyInstaller exe闪退:spec入口改main.py,main.py添加EASYOCR_WORKER环境变量检测跳转worker逻辑;build.bat只清理build/build和dist不删spec/hooks
3. QQ OCR _processed_path未定义:补充ts和_processed_path变量定义
@
2026-08-03 10:12:07 +08:00
youpaishidifu
30106571d7
修复4个问题:KB未回复诊断日志、微信唤醒bug、exe打包、截屏分目录
...
1. KB搜索命中但未回复:增加诊断日志记录每个检查步骤的失败原因
2. 微信窗口唤醒bug:增加Win32 API进程枚举兜底+可见窗口直接截图(不要求置前)
3. PyInstaller打包修复:自定义hook-torch.py避免isolated子进程access violation,
改用onedir模式+CUDA_VISIBLE_DEVICES=""环境变量
4. OCR截屏分平台存放:img/raw/qq/ img/raw/wechat/ img/processed/qq/ img/processed/wechat/
2026-08-02 23:44:43 +08:00
youpaishidifu
c853b3e504
fix(ocr): 页面文件不足防护——双重预检+长期冷却
...
问题:EasyOCR worker启动报 WinError 1455(页面文件太小),
无法加载 cufft64_11.dll,物理内存充足但虚拟内存(已提交32.5/35.7GB)不足。
修复:
1. worker端:import前预检虚拟内存——剩余<2GB则直接exit(2),不进入torch/easyocr加载
2. worker端:import捕获WinError 1455时写入虚拟内存诊断信息(物理/页面/提交率)
3. 父进程端:启动worker前预检虚拟内存——<2GB直接冷却1小时,不启动worker
4. 父进程端:识别exit(2)/页面文件错误——冷却1小时而非30秒(系统级问题不反复重试)
诊断增强:
- _get_virtual_memory_info():通过Win32 API获取物理/虚拟内存/页面文件状态
- 崩溃日志包含完整虚拟内存快照,便于排查
- 日志明确提示'增大Windows页面文件'
2026-08-02 21:35:33 +08:00
youpaishidifu
a858bbb9f6
fix(ocr): EasyOCR CUDA崩溃防护——健康检查+冻结隔离+自动降级
...
问题:EasyOCR worker启动即崩溃(access violation in torch CUDA),
冻住整台电脑,用户需强制重启。
修复三层防护:
1. worker端:CUDA健康检查——启动时创建小张量测试CUDA可用性,
失败则降级CPU,避免进入VGG模型加载的崩溃路径
2. 父进程端:CUDA_LAUNCH_BLOCKING=1——CUDA操作同步化,
access violation时只杀子进程不冻整机(关键防冻结)
3. 父进程端:崩溃检测——读取崩溃日志,含access violation/torch
则增加_easyocr_cuda_oom_count,第二次崩溃后强制CPU模式
(_easyocr_cuda_oom_count>=2 → EASYOCR_FORCE_CPU=1)
2026-08-02 21:22:59 +08:00
youpaishidifu
b21e8f8cd4
feat(ocr): 引入消息历史数据库,改进无时间戳消息放行逻辑\n\n问题:\n1. OCR识别不到时间戳则直接丢弃,如'领地系统依托于哪个插件'因无可见时间戳被丢弃\n2. 微信/QQ同时进消息时,总有一方的消息会被丢弃(待进一步排查)\n\n修复:\n- 新增MessageHistory类,使用SQLite记录用户消息和bot回复\n- 在bot回复时记录到数据库(三处回复路径均已添加)\n- 在ocr_text_has_fresh_timestamp中,无时间戳时增加上下文判断:\n - 若最近30秒内有bot回复(用户消息挨着bot消息):\n * 数据库无该用户消息记录 → 无条件放行\n * 数据库有记录 → 整段丢弃(防重复处理)\n - 否则保持原有逻辑(超短中文消息放行,其他丢弃)\n- 放行时记录用户消息到数据库,用于后续去重\n\n数据库:msg_history.db(SQLite),表message_history,字段:\n platform, sender_type(user/bot), content, content_hash(MD5), created_at\n\n验证:py_compile OK;数据库初始化自动创建表\n\n用户要求:'把用户消息、bot回复的消息做记录,如若用户的消息挨着bot的消息,且数据库无记录,无条件放行,如果用户的消息挨着bot的消息,无时间戳,数据库有记录,则整段丢弃。使用db保存。'
2026-08-02 21:01:33 +08:00
youpaishidifu
e0e5e05b10
fix(ocr): 乱码过滤器放宽——正常英文名词不再误杀\n\n根因:游戏UI乱码过滤器 regex CJK+大写英文 匹配'如何通过Minecraft...'中的'Minecraft',\n导致正常用户消息被误过滤。过滤器本意是捕获游戏UI公告/服务器列表中的乱码片段(如'玩家Ierite'),\n但无法区分正常英文名词。\n\n修复:在 CJK+大写英文过滤前增加中文字符占比检查——\n若中文字符数 >= 英文字母数,视为正常句子不过滤。\n三处过滤器均已修复:OCR(2183行)、剪贴板(2654行)、Poll(4328行)。\n\n示例:\n- '如何通过Minecraft的官网更新自己的皮肤?' → 中文10字母9,保留\n- '玩家Ierite' → 中文2字母6,过滤\n- '比武Mtp' → 中文2字母3,过滤
2026-08-02 19:49:15 +08:00
youpaishidifu
6f791622c9
fix(ocr): 引擎对比长度保护——Windows OCR截断丢消息
...
根因:_pick_ocr_text() 用 score >= score 选引擎,Windows OCR
虽然行数少(8行 vs EasyOCR 19行),但因垃圾字符少、空格惩罚低,
分数可能略高或持平,导致完整 EasyOCR 文本被丢弃。
修复:
- 新增长度保护:当一方行数 >=1.5x 且字符数 >=1.3x 另一方时,
分数差 <10 分则强制选更长文本
- 引擎对比日志增加行数/字符数/分数差,方便排查
- 不影响分数差距大时的正常选择逻辑
2026-08-02 17:51:27 +08:00
youpaishidifu
3853804ca4
fix: 急停/停止即时生效+基线吞消息永久拦截破除
...
问题1: 用户消息通过四层过滤器但不回复——根因基线轮吞消息后永久拦截:
- 基线轮 seen.add(item) 将历史消息永久加入 _seen_messages
- _last_sig 无条件更新 → 之后 OCR 每轮读到相同屏幕 sig 相同静默 return
- 双保险永久拦截: 用户重发相同内容永远等不到回复
修复: 基线轮 seen.discard(item) + 清空 _last_sig + 不 seen.add,
防重复改由 sig 静默跳过承担; sig 静默跳过加日志暴露(4131)
问题2: OCR 识别期间急停/手动停止不生效——主线程卡死在等待:
- _ocr_dual_engine join(timeout=10) 卡死
- _call_easyocr_safe queue.get(timeout=9) 卡死(EasyOCR子进程被杀后
proc.poll()!=None → _read_worker 立即退出 → _q 永空 → 等满超时)
- _safe_screenshot join(timeout=3) 卡死
修复: 三处等待全部改 while self._running 轮询(50ms粒度),
急停瞬间丢弃未出结果的 OCR 折返; _safe_screenshot 去 @staticmethod
验证: py_compile OK; 隔离测试 test_baseline_fix.py 4组断言全过
(基线后 seen 不含 item、sig 清空、重发触发回复、回复后防重复)
2026-08-02 16:44:00 +08:00
youpaishidifu
19c8817893
fix: 过滤器4 _is_reply_fragment 长度门槛6→4(≤4不参与匹配直接放行,≥4走完整匹配);日志拆分避免'7<6'误导(实际为_replied_texts空)
2026-08-02 15:12:16 +08:00
youpaishidifu
e9b9d6d92e
fix: QQ截图cap_left右移至25%避开消息列表时间戳; 修复未来时间戳误判为新鲜(14:40不能匹配16:00); 修复跨午夜反向边界+1day误用; 修复_is_markdown_document日志插入导致长文本检测死代码; 四层过滤器加日志
2026-08-02 14:53:46 +08:00
youpaishidifu
22e781edac
fix: 调整QQ截图裁剪参数cap_left=15%,添加噪声文本过滤
...
- QQ截图裁剪cap_left从0.10调整到0.15,避免截到左侧会话列表
- 新增_is_noise_text函数,过滤HTML标签、图片路径、OCR噪声等
- 在stage splitting主循环、尾部处理、_ocr_text_has_fresh_timestamp三处调用噪声过滤
- 语法检查通过
2026-08-02 12:34:32 +08:00
youpaishidifu
ad7aef5747
修复微信不唤醒前台+QQ裁消息+截屏定时随机清理
...
- 微信截图从不唤醒前台根因: _ensure_visible置前失败后'窗口可见即放行'
(IsWindowVisible&&!IsIconic→True), 截图截到被其他窗口压着的遮挡内容
(窗口停哪截哪, 用户实测原图证实)
- 修复: 微信分支改用_ensure_foreground(AttachThreadInput强置前),
必须真正前台才截图; 微信原生窗口安全(2630搜索联系人已用同路径)
- QQ裁剪继续往左放宽: cap_left 0.15→0.10 (15%仍裁掉左侧用户消息气泡边缘)
- 截屏清理改为定时随机: 原_clean_old_ocr_debug每次保存即按数量删(keep模式),
高频create+delete易触发360勒索误报; 新增_maybe_clean_ocr_dir()
每30~60秒随机间隔清理, 删除mtime早于60s的全部截图(raw+processed都清),
5处保存点去掉立即清理, 死函数已删, 挂载_run_loop主循环
2026-08-01 23:50:04 +08:00
youpaishidifu
4428042703
修复OCR捕捉不可见旧消息+微信无图可查+急停/停止/启动计数器清零
...
- 不可见消息被回复根因: stage splitting主循环+尾部处理中 last_ts=None 时
buf无条件append(首行消息在时间戳之前=更早历史, 绕过全部新鲜性检查)
→ 22:35:33日志实锤: '单清效果是清理哪些效果?'(早已被覆盖)被OCR精准捕捉并回复
- 修复: ① 主循环 if not last_ts: 视为历史丢弃(首个时间戳之前的消息)
② 尾部处理 if not last_ts: 丢弃(整行无时间戳归属)
③ _ocr_text_has_fresh_timestamp 无时间戳不再无条件True, 仅≤4字中文超短消息放行
- 微信无图: 22:35:26 _ensure_hwnd超时(12s)整轮跳过无截图; 现在
_ensure_visible失败时保存'窗口不可见现场截图'(尺寸过滤), 每次尝试都留图
- 计数器清零: start()/stop()缺_easyocr_consecutive_failures重置,
_emergency_stop()急停完全不重置; 三处统一清零
consecutive_failures/cuda_oom_count/call_count/retry_until/broken
+ OCR状态(截图hash/垃圾计数/引擎选择/回复冷却/上次文本)
= 重启后CUDA降级/超时计数不残留, 从头评估GPU/CPU
2026-08-01 22:57:54 +08:00
youpaishidifu
4ae189e82f
修复EasyOCR CUDA OOM冻结+时间戳day=0崩溃+OCR图片分目录img/raw+processed
...
- 冻结根因: CUDA OOM后worker不退出, 损坏context持续占显存, 父进程不杀子进程
反复发图→线程堆积+显存耗尽→桌面冻结
- worker: readtext CUDA/kernel错误→立即退出释放显存(faulerhandler已有兜底)
- 父进程: 收到CUDA错误→立即杀子进程+30s冷却; 连续2次CUDA错误→EASYOCR_FORCE_CPU=1
强制CPU模式启动(显存不足降级防冻结)
- 时间戳day=0崩溃: _is_timestamp_old跨午夜用replace(day-1), 每月1号day=1→day=0
抛ValueError day is out of range for month→微信OCR整轮失败; 改用timedelta(days=±1)
- OCR调试图片回源码目录: img/raw(原图PNG) + img/processed(处理后JPG) 分目录存储
- 崩溃日志回源码根 easyocr_crash.log (不写%LOCALAPPDATA%)
- _clean_old_ocr_debug 默认 keep=20 (回退上一轮激进keep=6)
- .gitignore: 忽略 img/ 与 worker_stderr/stdout.txt
2026-08-01 22:23:55 +08:00
youpaishidifu
0405e42a90
修复OCR回复牛头不对马嘴+残留消息+EasyOCR崩溃捕获+360误报
...
1. knowledge_base.py: 检索排序惩罚标题-only/短正文段,降低heading bonus,奖励正文命中,避免纯标题/免责声明段排第一
2. auto_reply.py: 动作类查询要求正文命中才放行;拒绝纯标题/免责声明答案
3. monitor.py: 调试截图改存%LOCALAPPDATA%/windowmsgbot/ocr_debug避开源码目录(360); 收紧残留消息fresh gate(600s硬门); 启动即崩溃/请求崩溃时读取easyocr_crash.log写入主日志
4. easyocr_worker.py: 加faulthandler+sys.excepthook全局捕获,崩溃traceback落盘%LOCALAPPDATA%/windowmsgbot/easyocr_crash.log
2026-08-01 21:21:05 +08:00
youpaishidifu
9ff019df00
fix: EasyOCR inner timeout mismatch + fresh timestamp gate放宽
...
1. EasyOCR inner timeout 30s→_OCR_TIMEOUT-1(9s)
外层join 10s,inner必须<外层,否则线程永远alive跳过
2. _ocr_text_has_fresh_timestamp: 时间戳全过期但含新鲜内容特征时放行
旧时间戳后紧跟新消息(无独立时间戳)不再被整批丢弃
2026-08-01 18:09:26 +08:00
youpaishidifu
8cf28d11bc
EasyOCR容错: 连续3次超时才杀进程, 前2次保留子进程预留初始化时间, 单次OCR超时保持10s
2026-08-01 17:15:57 +08:00