|
|
fb9b6c4f6e
|
feat: 抓取期间每 60 秒打一次进度心跳
单场秀几百张图要抓几十分钟，期间 done 不变。
后台按「progress_at 超过 10 分钟没变」判卡死，会把正常但慢的抓取误报成卡死。
心跳只刷新时间戳，不改进度数字。
|
2026-10-25 20:50:05 +08:00 |
|
|
|
7fce365d75
|
feat: 上报抓取进度（后台显示 3/25 场 · 正在抓什么）
一次品牌抓取可能跑几十分钟，此前后台只有 running/done 两个状态，
看不到「在干什么」，也分不清「慢」和「卡死」。
- getDetail 进/出一场各打一次点（含 404 等失败场次，避免进度永远差几场）
- 总数在「预检过滤 + 场次上限」之后定格，与实际要抓的场次一致
- 只对 TaskID != 0（serve 模式）上报，单机 vogue 模式不上报
|
2026-10-25 20:33:45 +08:00 |
|
|
|
934a8961b0
|
fix: 抓取前预检已入库的秀，避免重复下载（重爬 62 分钟 0 新增）
问题：图片 key 是内容 sha1，不下载就无法判断是否已存在；
后端又没存 source_url，无法做 URL 级判重。
于是每次重爬都把几百张已下过的图再下一遍 —— 线上实测
Celine 跑了 62 分钟、约 600MB，入库 0 新增。
修复：
- 后端新增 GET /admin/internal/shows/covered?brand_uid=
按 (年份, 季节, 类型) 聚合已入库图片张数
- spider 抓取前预检，整场已入库（>=10 张）就跳过，一张图都不下载
- 加 --force 可强制重抓（默认跳过）
- 媒体直传并发改为全进程共享信号量：此前秀级 2 × 每场 6 = 12 路
同时打 Vogue，被限流后单张从 9.8s 掉到 ~90s
- 批次下载失败时打印第一条错误（此前只统计个数，查不出原因）
|
2026-10-25 20:07:54 +08:00 |
|
|
|
3fe0b86e11
|
feat: 媒体机直传 + 向量回填
- media: spider 下载图片后按内容 sha1 生成 key，经后端预签名直传 S4，上报只带 key
（spider 不持有 AK/SK；单张失败自动回退为上报 URL）
- embed: 新增 embed 子命令，从后端领取缺向量的图片→下载→本地 CLIP 编码→回传
（媒体拆分后后端拿不到图片字节，向量只能靠回填补齐）
- serve: 服务化常驻模式（领取 crawl 任务 → 抓取 → 回报）
- config: 新增 media.upload/concurrency、vision.endpoint/concurrency
|
2026-10-25 00:27:46 +08:00 |
|
